En av mina personliga lärdomar av det senaste årets diskussion om Internet-säkerhet är att vi måste kryptera mera. Släppa på några gamla heliga kor och separara andra glorifierade nötkreatur från varandra. Låt mig beskriva hur jag tänker!

I min värld har jag mumlat att om man inte kan verifiera SSL- eller TLS-servern så är det ingen poäng att kryptera. Det blir ju inte hemligt, liksom.

Olle E. Johansson

Nu börjar jag ana att det är att blanda begreppen – kryptering som ger konfidentialitet och autenticering som hjälper oss att avgöra om vi kommunicerar med rätt tjänst eller person. Man kan kryptera utan att autenticera. Det blir kanske inte samma nivå av konfidentialitet, men det blir svårare för utomstående att läsa trafiken. Inte omöjligt, men svårare och kostsammare. Vi måste höja ribban ett par steg. Datakraft blir allt billigare, så att kryptera mera kommer inte att påverka CPU-användningen speciellt mycket. Att inte ens försöka kryptera är i dagsläget att släppa allting helt fritt för alla.

TLS och SSL – vad är det?

TLS och SSL är standarder för autenticering och kryptering av IP-kommunikation. SSL, Secure Socket Layer, utvecklades av Netscape Communication och var ett registrerat varumärke. Standarden överfördes senare till IETF och bytte namn för att undvika varumärket. Det nya namnet är TLS – Transport Layer Security. SSL version 3 och TLS version 1.0 var jämförbara. Idag är SSL v1 och v2 osäkra och ska helst inte användas.

IETF tar allvarligt på det som hänt – det är en attack mot Internet!

IETF har sett allvarligt på alla avslöjanden om avlyssning av Internet. Man har insett hur enkelt det är och vilka brister protokollen vi jobbar med har. Nu höjs ribban samtidigt som man sätter in krafter på att utveckla nya rekommendationer, riktlinjer och regler för hur nya protokoll definieras. Säkerhet ska in från början i designen, inte läggas till som en eftertanke.

Det finns en ny arbetsgrupp inom IETF som heter UTA där man försöker reda ut hur vi kan få mer krypterade sessioner i applikationslagret. Paul Hoffman, har skrivit en första version av en draft där han försöker reda ut begreppen och definiera ”opportonistic crypto” ur TLS-synpunkt. Det finns flera grupper som jobbar och begreppet kommer förmodligen manglas i ett par olika omgångar innan man enas, vilket dock inte hindrar att det används flitigt. Jag tycker att Pauls draft lärde mig mycket. Läs den!

https://tools.ietf.org/html/draft-hoffman-uta-opportunistic-tls-00

I korthet säger han att ”opportunistic crypto” är när programvaran och systemen sätter upp TLS för att man kan, inte för att användaren krävt det. Om du surfar till en webb som har både port 80 och 443 öppen så ska webbläsaren välja att använda TLS oavsett vad URL är. Skillnaden är att när programvaran fattar beslut och sätter upp krypto – kanske utan att kunna verifiera certifikat, så ska INGET lås visas, ingen address ska visas i grönt och användaren ska inte få något felmeddelande om att ”Bussiga Olles billiga CA är en okänd certifikatutfärdare du inte ska lita på”.

#MeraKrypto – nu är det dags att öka mängden TLS på nätet!

VI i ISOC-SE i samarbete med SNUS och andra organisationer kommer jobba mer med det här under resten av året. Många frågor uppstår – hur kan vi mäta framgång i det Svenska Internet? Mer TLS i mailsystemen? Mer TLS på webben? Mer TLS i IP-telefoni – SIP?  Kan vi få igång mer DANE eftersom vi är föregångare med DNSSEC? Hjälper verkligen mera krypto eller är det andra lösningar vi behöver? Är TLS för gammalt och ska helt enkelt ersättas? Här finns att snacka om och det ska vi göra. Lära oss mer, så vi kan påverka där vi jobbar dagligen.

Vi är några som jobbar med det här i IETF och kan rapportera tillbaka. Leif Johansson på Sunet är co-chair för UTA-gruppen. Jag rotar som vanligt i SIP och WebRTC. Daniel Stenberg är med i arbetet runt HTTP 2.0 som troligen bara kommer använda TLS. Jakob Schlyter jobbar med DANE och DNSSEC. Vi är dessutom många som jobbar med Open Source och kan förändra synsättet. Det finns redan lösningar för ”Better Than Nothing” kryptering i IPsec. Jag har redan börjat rota med mina kollegor som utvecklar SIP-lösningar om hur vi kan förändra koden så vi alltid sätter upp TLS där vi kan. SIP-protokollet tillåter det utan att vi ändrar en enda rad i raden av RFC som beskriver IP-telefoni! Det är bara koden som ska göra rätt. SIP-telefonen Jitsi gör det redan. Små steg framåt, men ack så viktiga.

Slå på säkra sessioner i dina molntjänster!

Du kan också göra små saker, även om du inte är utvecklare. Använd Facebook, Google, LInkedIN och andra tjänster över TLS. I många fall finns inställningar där du säger att du vill att alla sessioner, oavsett URL, ska använda TLS.  Om tjänsten inte stödjer TLS, så maila och fråga varför. Om ingen knackar på dörren, så märks vi inte.

Bygg in TLS i appar och molntjänster!

Om du är med att bygga appar för mobiler, sätta upp servertjänster eller utvecklar system – se då till att TLS är med i designen från början. Precis som IPv6 är det lättare att ha det med i starten så att det blir rätt. Välj nivå efter applikationens värde – ska certifikat valideras, ska ni ha en egen certifikattjänst, ska ni ha säker identitet? Oavsett vilken nivå av säkerhet ni väljer för er IT-lösning, så se till att alla sessioner krypteras.

En enkel presentation – #MoreCrypto

Jag har satt samman en del av mina tankar i en kort presentation. Jag går inte in på val av algoritm, serverkonfiguration eller programmerings-gränssnitt till OpenSSL. Det handlar mer om varför vi måste förändra vårt synsätt och steg vi måste ta tillsammans för att säkra vårt nät.