Net iD Service
 

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

Sidan granskad/uppdaterad: 2017-04-05

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 att just din kombination av operativsystem och webbläsare är supporterad

4)
Stänga av den automatiska återställningen efter krasch i Internet Explorer.
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.

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 eller Chrome för att se alla URLer som passeras.
Utan denna konfiguration kan processens (flikens) ID ändras under resans gång => Då blir NetControl maktlös eftersom den PID som ska stängas inte längre finns!

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 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.

 

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". Men att använda Watch på det sätter skalar inte riktigt om man har många många webbtjänster som användarna använder.

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. (men vem kör iPlanet idag?) 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:

Kodsnutt:

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:

 

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:

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

Nu finns det som tur är ett sätt att hantera detta med IE 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.

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.

 

Särskilt om Firefox

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:

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

 

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.

Minns även att ytterst vilar ansvaret på att inte lämna patientdata uppe på skärmen när man lämnar datorn vilar på användaren själv.