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.