Hur få webbläsaren att stängas när man rycker kortet?

Betrodda platser blir allt viktigare!

Allt fler siter hanterar inloggningen med hjälp av SAML. Men ofta hanteras inloggningen mot iDPn via vanlig dubbelriktad SSL och då registrerar Net iDs funktion ‘NetControl’ aktuell IE-fliks PID. Men då många lösningar bygger på ett antal redirects uppstår ett ”PID-fladder” som gör att den PID som gällde vid TLS/SSL-förhandlingen med iDPn senare inte gäller när man väl är inloggad på den egentliga siten. Det är därför viktigt att lägga in alla inblandade hostar i zonen ”Betrodda platser”. Då verkar PID-fladdret upphöra och Net iD NetControl kan stänga sessionen om kortet rycks.

Bakgrund

Många webbapplikationer nyttjar dubbelriktad TLS/SSL för inloggning. Det är en mycket smidig, standardiserad och lätt uppsatt lösning. Vissa tycker dock att en helt plug-in baserad inloggning över enkelriktad TLS/SSL är att föredra men att gå runt och föredra saker hjälper ju föga om lösingarna de facto använder dubbelriktad TLS/SSL. Hursomhelst, det finns dock en baksida med dubbelriktad TLS-SSL: Utloggningen

Det är tyvärr så (på gott och ont) att dagens webbläsare frenetiskt cachar allt som går att cacha inklusive allt som rör TLS/SSL-sessioner.
Då det inte är ovanligt att uppstädningen på serverside saknar någon viktig del försöker vi göra vad vi kan på vår kant med hjälp av funktionen Net iD NetControl. Det är helt enkelt en liten funktion som stänger de applikationer som man konfigurerat Net iD att stänga om dessa applikationer använts för att upprätta en TLS/SSL-förbindelse.

För att säkerställa att din webbläsare stängs när kortet tas ur kortläsaren behöver du beakta följande

1)
Se till att ha den senaste drivrutinen för din kortläsare.
SecMaker rekommenderar att man kör tillverkarens egen drivrutin, ej den generella CCID-drivaren i Windows från 2006. Dåliga läsare/drivrutiner har en tendens att missa när ett kort rycks och då är Net iD NetControl-funktionen helt maktlös.

2)
Kontrollera att ditt Net iD-paket verkligen paketerats för att stänga just din webbläsare och att ingen fråga skall ställas till användaren. De generiska paketen för SITHS är sedan en tid tillbaka konfigurerade för att stänga följande läsare utan att fråga användaren om lov: iexplore.exe;firefox.exe;safari.exe;chrome.exe;iidxweb.exe
Lämpligen testar man med ett webbläsarfönster och en flik och loggar på mot denna site och rycker kortet

3)
Kontrollera i matrisen nedan att just din kombination av operativsystem och webbläsare är supporterad
(Matrisen håller på att uppdateras men du kan alltid kontrollera om din webbläsarversion släpptes EFTER din Net iD version, då är kombinationen per definition inte supportad)

4)
Stänga av den automatiska återställningen efter krasch i Internet Explorer och Firefox.
Webbläsarna uppfattar ofta NetControls nedstängning som en ”krasch”.
Se denna bild för hur man stänger av automatisk återställning efter krasch i IE.
Se denna bild för hur man stänger av automatisk återställning efter krasch i FF.

5)
Kör helst inte känsliga webbapplikationer i en flik sida vid sida med andra flikar. Kör i separata fönster, helst startade med växeln ”-nomerge”. Se denna bild för hur man startar IE med denna växel

6)
Se till att alla inblandade sajter ligger i zonen ”Betrodda platser” eller ”Intranät”. OBS! Om sajten använder federation är det aldrig bara en sajt inblandad. Använd F12 i IE för att se alla URLer som passeras.

7)
I värsta fall får man ta till knepet med TabProcGrowth! Det kan man läsa om här:

http://blogs.msdn.com/b/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx

Artikeln ger tips om ett hyss man kan överväga att ta till, dvs. sätta denna registernyckel:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\TabProcGrowth till 0.
Då ligger alla fönster och alla flikar under samma processID och då ryker hela rasket vid kort ur.
(bra om personalen informeras)
Artikeln innehåller även en förklaring till att bara vissa flikar stängs när man har riktigt många flikar och att det kan se helt slumpmässigt ut beror på IE’s algoritm för hur processIDn allokeras.

OBS!

Ingen av de ovanstående åtgärderna spelar någon roll om:

a) Webbapplikationen som sådan sätter cookies på ett sådant sätt att allt som behövs för återtagande av sessionen ligger kvar lokalt.

b) Det finns en extra flik igång som kan återanvändas för den säkra sessionen efter att den första fliken stängts

Problemet verkar finnas i vissa lösningar som redirectar till en IDP och hur SAML-biljetter, artefakter och cookies hanteras.

Ett ”OK” i tabellen nedan betyder alltså att Net iD stänger ner korrekt fönster/flik men att det kan finnas problem med vissa specifika webbapplikationer och/eller webbläsare. I dessa fall finns en not angiven

Cookiefelet är dock ej noterat eftersom det slår generellt

Ett bättre sätt att hantera hela problemställningen!

Om man loggar på sin dator med kort och har satt sina policies rätt eller använder Net iD Watch alternativt kör alla viktiga webbapplikationer via t.ex. Citrix är hela denna problemställning irrelevant. Då låser man datorn eller disconnectar sessionen istället för att bry sig om webbläsarnedstängning
Om du kör Net iD på en Citrixserver stängs webbläsaren inte ner. Detta är helt korrekt eftersom funktionen Net iD NetControl vanligtvis är avstängd i Net iD-paket för servrar. Tanken är att konfiguration skall ske på annat sätt för att göra disconnect på Citrix-sessionen snarare än att stänga ner webbläsaren.

Kortläsare

HP

Många av våra kunder använder tangentbord från HP med kortläsare. Det finns tre varianter:

1.
Modellnummer KUS0133 med rektangulär HP-logotyp och kortläsare typ ”A
Till denna variant har HP egna drivrutiner. 4.33.0.0 är den senaste.
Vid=03F0
PID=1024

2.
Modellnummer KUS0133 med rektangulär HP-logotyp och kortläsare typ ”B
Till denna variant har HP inga egna drivrutiner utan hänvisar till Microsofts generella drivrutiner. (CCID)
Vid=03F0
PID=0036
Denna variant är tämligen sällsynt. Troligen få som har denna kombination.

3.
Modellnummer KUS0133 med rund HP-logotyp och kortläsare typ ”B
Till denna variant har HP inga egna drivrutiner utan hänvisar till Microsofts generella drivrutin. (CCID)
Vid=03F0
PID=0036

4. Alcor Micro
Denna kortläsare har haft en mödosam uppväxt. Om du genomför alla de uppforstringsårtgärder som finns beskrivna på vår särskilda kortläsarsida så sköter sig den dock hyfsat. Kika på denna sida för detaljer om kortläsare!

Dell

Vissa av våra kunder använder tangentbord från Dell med kortläsare. Den senaste drivrutinsversion för XP vi hittat är:

4.0.8.5

Den är svår att hitta på Dells hemsida. Du hittar den dock här:

Dell_Smartcard_Keyboard

Information om de tester som gjorts vid framtagandet av ovanstående matris:

Test 1
Ett fönster öppnat
Inloggad i SITHS Admin
Rycker kortet

Test 2
Två fönster öppnade
Inloggad i SITHS Admin i det ena och i Apotekets webbtjänst i det andra
Rycker kortet

Test 3
Två fönster öppnade
Inloggad i SITHS Admin i det ena och Google i det andra (ej SSL alltså)
Fönstret utan SSL i fokus
Rycker kortet

Test 4
Två flikar öppnade i samma fönster
Inloggad i SITHS Admin i den ena fliken och mot Apoteket i den andra
Rycker kortet

Test 5
Två flikar öppnade i samma fönster
Inloggad i SITHS Admin i den ena och Google i den andra (ej SSL alltså)
Rycker kortet

OBS! Om test 5 görs med Apotekets webbtjänst i flik 1 istället för SITHS Admin kan sessionen återtas med hjälp av flik 2. Detta beror inte på Net iD utan på att Apotekets tjänst behåller sessionsdata på ett sådant sätt att återanslutning kan ske helt utan kort så länge webbläsaren inte stängts ner helt. Undvik därför att köra känsliga webbapplikationer i fönster med flera flikar. Ett ”OK” utan kommentar i matrisen nedan handlar alltså endast om att Net iD gör rätt i det aktuella testfallet.

Testet genomfördes med flera olika kortläsare men alltid med leverantörens senaste drivrutin.
Net iD NetControl var i alla testfall inställd på att stänga ner utan att fråga användaren om lov.
Vid testet användes ett kort med profilen ”Telia EID IP2”

Matris över nedstängning av webbläsare när kortet rycks

 Net iD
5.3.0.28
(8/2 2010)
Net iD
5.5.0.27
(7/2 2011)
Net iD
5.6.1.53
(10/11 2011)
Net iD
5.6.2.62
(15/3 2012)
Net iD
5.6.3.64
(13/8 2012)
Net iD
6.0.2.49
(10/7 2013)
Test med Windows XP SP3
IE 7.0 OK
(1)
OK
(1)
OK
(1)
IE 8.0 OK
(2)
OK OK
Firefox 3.6.24 ERROR
(5)
OK
(3, 4)
OK
(3, 4)
Firefox 8.0 Not supported Not supported OK
(3, 4)
Firefox 11.0 Not supported Not supported Not supported
Firefox 23 Not supported Not supported Not supported Not supported Not supported
Net iD Web Client OK
Test med 32-bit Windows 7 SP1
IE 8.0 32-bit OK
(2)
OK OK
IE 9.0 32-bit
(Släpptes 14/3 2011)
Not supported Not supported Not supported
IE 10 Not supported Not supported Not supported Not supported Not supported
Firefox 3.6.24 ERROR
(5)
OK
(3, 4)
OK
(3, 4)
Firefox 8.0 Not supported Not supported OK
(3, 4)
Firefox 11.0 Not supported Notsupported Not supported
Firefox 23 Not supported Not supported Not supported Not supported Not supported
Chrome
18.0.1025.162 m
Not supported Not supported Not supported XX
(formellt är det 16.0
som 5.6.2 supportar)
Chrome
28.0.1500.95 m
Not supported Not supported Not supported Not supported Not supported
Net iD Web Client Ej testat
Test med 64-bit Windows 7 SP1
IE 8.0 32-bit OK
(2)
OK OK
IE 8.0 64-bit Ännu ej testat Ännu ej testat Ännu ej testat
IE 9.0 32-bit
Släpptes 14/3 2011
Not supported Not supported OK OK
IE 10 Not supported Not supported Not supported Not supported Not supported
Firefox 8.0 Not supported Not supported OK
(3, 4)
Firefox 11.0 Not supported Not supported Not supported
Firefox 23 Not supported Not supported Not supported Not supported Not supported
Chrome
18.0.1025.162 m
Not supported Not supported Not supported XX
(formellt är det 16.0
som 5.6.2 supportar)
Chrome
28.0.1500.95 m
Not supported Not supported Not supported Not supported Not supported
Net iD Web Client OK
Test med 64-bit Windows 7 SP1 och officiellt osupportade webbläsare
Safari 5.1
VARNING
Helt undermålig certifikatvalslogik
TDB
Opera
Saknar vettigt stöd för certifikat
TBD
 Linux
Firefox NetControl finns ej för Linux. Använd Net iD Watch.
MacOSX
Safari NetControl finns ej för Mac. Använd Net iD Watch.
Firefox NetControl finns ej för Mac. Använd Net iD Watch.

1) Vid test 5 med Internet Explorer 7 stängs båda flikarna även om bara den ena varit inblandad i TLS/SSL-förhandling med kortet. Med Net iD 5.3 kan en delay på upp till 15 sekunder upplevas innan alla flikar stängts.
2) Med Net iD 5.3 kan en delay på upp till 15 sekunder upplevas innan alla flikar stängts. (Test 4)
3) När kortet rycks stängs alla Firefox-fönster/flikar eftersom Firefox har samma processID för alla fönster/flikar
4) Session mot apoteket.se kan återtas ÄVEN om hela Firefox stängs ner. Därför är det viktigt att sätta ”browser.sessionstore.resume_from_crash” till ”false” i Firefox.
5) När kortet rycks stängs INTE Firefox men så snart man klickar på någonting i webbapplikationen tar det stopp. Dock ej på siter typ Apoteket, där kan man därför lugnt botanisera vidare utan kortet i.
Undvik således kombinationen FF 3.6.024 och Net iD 5.3.
(Notera att 3.6.24 släpptes efter Net iD 5.3)
Internet Explorer 6 was released on August 27, 2001
Internet Explorer 7 was released on October 18, 2006
Internet Explorer 8 was released on March 19, 2009
Internet Explorer 9 was released on March 14, 2011
Windows 7 was released to manufacturing on July 22, 2009, and reached general retail availability on October 22, 2009
Bakgrundsinformation om utloggning

Webbläsare cachar som bekant sessionsID vilket innebär att man kan hamna i ett läge där återanslutning kan ske helt baserat på cachad information. Kortet behöver inte ens sitta i kortläsaren, inget certifikat väljas och ingen PIN-kod anges.
Men det finns många ställen att rensa på för att verkligen se till att en användare är utloggad så man kan inte helt förlita på endast en metod:

1) Applikations-logout

Detta måste ske i webbapplikationens eget applikationsskikt förstås. Här är inte Net iD inblandad alls om inte Net iD Watch nyttjas och konfiigureras att skicka ett särskilt anrop till serverside baserat på ”kort ur”.

2) Serverside SSL-logout

Det finns lösningar för att döda specifika sessionsIDn på serverside. Då kopplas denna funktion till e-tjänstens ”Logga ut”-knapp. För iPlanet/SunOne finns en sådan funktion som standard. Kör man Apache så får man skriva en sådan modul själv. Det har t.ex. Skatteverket gjort. Hur man gör om man har IIS är ännu inte utforskat.

3) Clientside SSL-logout

Här måste vi använda en metod som webbläsaren själv svarar på. Net iD är inte inblandad alls i detta.

4) ”Kort-logout”

Här handlar det om att ”släppa kortet”, dvs. göra så att PIN-koden måste anges igen. Detta görs via Net iD:s plugin. Se exempel nedan.

Mer om ”Clientside SSL-logout”

Det finns ett anrop som rensar webbläsarens authentication cache;

document.execCommand("ClearAuthenticationCache");

Kommandot fungerar i IE 6.0 SP1 och senare men tyvärr inte i Firefox. Det finns en flera år lång tråd på Bugzilla om detta:

https://bugzilla.mozilla.org/show_bug.cgi?id=287957

Om du kör detta kommando i din kod ska du få upp certifikatvalsdialogen igen, men PIN behöver du inte slå. Dvs. SSL-förhandlingen görs om men PIN slipper du slå oavsett om du har Net iD med SSO eller inte, du är kvar i samma process och även Net iD utan SSO-modulen cachar PIN för befintlig session. Notera att certifikatsvalsdialogen endast visas om du bara har ett certifikat som siten accepterar och samtidigt har ställt in IE såhär, vilket är default i IE:

morethanonecert

Kodsnutt:

clearssl

OBS! Om du använder detta anrop riskerar du att även andra sessioner i andra fönster/flikar ryker all världens väg. Men det kan det ju vara värt, kanske.

Mer om ”Kort-logout”

Det finns ett sätta att via Net iD:s plug-in logga ut från kortet/mjukt token. Gör man detta ska man få upp certifikatvalsdialogen igen och PIN måste anges. Dvs. SSL-förhandlingen görs om och ”kopplingen till kortet” har ”släppts”, därför måste du slå PIN igen oavsett om du har Net iD med SSO eller inte. Rörande certifikatsvalsdialogen vara eller inte vara gäller samma som ovan beskrivet.
OBS! Om du använder detta anrop riskerar du att andra applikationer störs givet att dessa är beroende av kortet eller ditt mjuka token.

Kodsnutt för både cache och Net iD:

clearsslandlogout

Bakgrundsinformation om sessioner

I Net iD har alltid funktionen ‟Net Control‟ funnits. Funktionen håller via sessionernas process-ID koll på vilka som nyttjat kortet för inloggning med klientcertifikat via SSL. När klientcertifikatet ”försvinner”, dvs. när användaren drar kortet ur kortläsaren, stängs sessioner som har ”använt kortet”. Oftast handlar det om att man kör Internet Explorer (IE) mot en webbtjänst, drar kortet och IE stängs.

Vilken information är då en del av en session? Det är fyra delar, inte bara cookies:

1 – Session cookies
2 – sessionStorage
3 – HTTP Authentication (e.g. Digest or Basic HTTP credentials)
4 – HTTPS Client Certificates (e.g. sites that use certificates or SmartCards)
För att rensa klientens sessionsdata rörande certifikat nyttjade för HTTPS-uppkopplingar borde alla webbapplikationer ha följande logik kopplad till en logoutknapp, stöds av IE6 SP1 och senare:

document.execCommand("ClearAuthenticationCache");

Läs mer detaljer om detta:
http://blogs.msdn.com/ieinternals/archive/2010/04/05/Understanding-Browser-Session-Lifetime.aspx

Men inte alltid är det så att användarna kommer ihåg att klicka på ”Logga ut” på webbsidan eller stänga IE med krysset. De tar sitt kort och går och det kan man ju förstå, ibland är det bråttom.
Kör man alla sina webbapplikationer publicerade via t.ex. Citrix med korrekt uppsatt sessionshantering så vore inte detta något problem. Inte heller om man loggar på sin dator med kort och sätter GPO för Lock Workstation. Men så ser det ju inte alltid ut…

Här är en användare inloggad med sitt kort mot två välkända webbaplikationer:

two_windows
Ett antal sekunder efter att kortet dragits ur kortläsaren stängs den ena session medan den andra återskapas av IE:s kraschskydd. Dock utan att lyckas. Men det finns siter mot vilka IE lyckas cacha allt den behöver och man kan jobba vidare utan kort, inte bra.

Särskilt om Internet Explorer 8

Nu finns det som tur är ett sätt att hantera detta med IE 8 tack vara startparametern: ”-nomerge”
Om man ser till att IE alltid startar separata sessioner, motsvarande att klicka på ‟Arkiv – Ny session‟, så delar de olika IE-fönstren inte processer och det hela fungerar bra, så länge vi talar om olika fönster. ”-nomerge” hjälper oss inte om man envisas med att köra i flera flikar.

ie-nomerge

Det kan också vara klokt att stänga av kraschskyddet både i IE 7, 8 och 9 för att förhindra att webbläsaren försöker återskapa sessionen efter att ha blivit nedstängd.

IE_craschprotect_disable

Särskilt om Firefox 5

1) Trots diskussioner sedan 2006 kan man inte programmatiskt be Firefox att radera sin cache. Det kan väl möjligen förklaras med att användare normalt sett inte vill få sin cache raderad. Men detta är i sanning ett behjärtansvärt fall. Diskussionerna fortsätter, dels inom Gecko-lägret (Firefox) och dels inom WebKit-lägret (Google Chrome och Apple Safari)

2) Net iD NetControl stänger ner Firefox när kortet rycks, men när detta sker sparar Firefox hela sessionen inklusive sessionsID från TLS/SSL-förhandlingen. När man sedan startar Firefox igen så återskapas sessionerna. Ibland efter att först ha frågat men inte alltid.

Förhindra detta genom att göra denna inställning:

2

3) Om man vill att t.ex. en knapp på sidan ska stänga Firefox behöver man göra denna inställning:

dom_allow_scripts_to_close_windows

Test med Pulsen Combine

combine_001
Noteringar av effekter av användandet av document.execCommand(”ClearAuthenticationCache”);

Test 1

a) Startar IE9 på vanligt sätt, loggar på Combine i en flik och service.secmaker.com i en annan flik
b) Trycker ”Logga ut” i Combine
Resultat
# Om jag klickar på något inne på service.secmaker.com i den andra fliken måste jag välja certifikat, men behöver ej slå PIN
# Jag kan logga in i Combine igen i den första fliken. Måste välja certifikat men behöver ej slå PIN
Förväntat beteende

Test 2

a) Startar två separata IE9-fönster på vanligt sätt, loggar på Combine i ena fönstret och service.secmaker.com i det andra
b) Trycker ”Logga ut” i Combine
Resultat
# Om jag klickar på något inne på service.secmaker.com i det andra fönstret måste jag välja certifikat, men behöver ej slå PIN
# Jag kan logga in i Combine igen i det första fönstret. Måste välja certifikat men behöver ej slå PIN
Förväntat beteende

Case 3

a) Startar två separata IE9-fönster, båda med växeln ”-nomerge”, loggar på Combine i ena fönstret och service.secmaker.com i det andra
b) Trycker ”Logga ut” i Combine
Effekter
# Eftersom ClearAuthenticationCache gjordes i en annan process kan jag klicka runt inne på service.secmaker.com i det andra fönstret.Sessionen kvar.
# Jag kan logga in i Combine igen i det första fönstret. Måste välja certifikat men behöver ej slå PIN
Förväntat beteende

Case 4

a) Startar två separata IE9-fönster, båda med växeln ”-nomerge”, loggar på Combine i ena fönstret och service.secmaker.com i det andra b) Trycker ”Logga ut” på service.secmaker.com (som inte bara gör ClearAuthenticationCache utan även utloggning från kortet)
Resultat
# Klickar jag på något i Combine så säger den ”Ingen kontakt med tjänsten”
Förväntat beteende

Case 5

a) Startar IE9 på vanligt sätt, loggar på Combine i en flik och kör svt.se i den andra
b) Rycker kortet med svt.se-fliken aktiv
Resultat
# Combine-fliken blinkar (det är er dialog som poppat upp) men fliken stängs inom några sekunder
# Öppnar ny flik utan att stänga ner hela IE och loggar på Combine, måste både välja certifikat och slå PIN (bra)
Förväntat beteende

Slutsatser

Om man jobbar mot flera webbsiter som kör SSL samtidigt är det klokt att jobba i separata fönster som startats med växeln ”-nomerge” istället för i flera flikar i samma fönster.

Man bör vara försiktig med att använda den möjlighet som Net iD:s plugin ger. Dvs. att tvinga fram en utloggning från kortet. Funktionen finns att se och testa på service.secmaker.com, (document.iID.Invoke(‘Logout’);)

Avslutning

SecMaker tar gärna en dialog med alla olika aktörer med intressen i detta: IT-avdelningar, utvecklare, säkerhetskonsulter samt SITHS-förvaltning. I nuvarande läge med en hotbild mot alla webbläsare vet vi inte hur länge en funktion som NetControl kan fungera. Vi funderar bl.a. på om inte webbtjänster av stort strategiskt värde borde få en signal om ”kort ur” via ett webbservice-anrop som på serversida kan resultera i olika åtgärder som omöjliggör sessionsåtertagning alldeles oavsett hur mycket webbläsaren lyckats cacha. Vi önskar initiera en diskussion med journalsystemleverantörerna om hur de initierar sina uthopp till webbapplikationer ”vid sidan av”. Kanske bör dessa uthopp ske med ovanstående IE-växel?

I praktiken kan inte en PKI-klient som Net iD:s lösa detta problem till fullo. Lösningen bör fokusera på att serverside implementerar en avloggningsfunktion som raderar sessionen ända ner på SSL-nivå eller åtminstone omöjliggör att en befintlig SSL-session inte kan återanvändas för inloggning till själva applikationen och därmed kunna nå information.