Taggat med: SSL/TLS

Oberoende granskning av OpenVPN

OpenVPN är ett otroligt populärt verktyg för att skapa upp VPN-anslutningar och används av majoriteten av alla VPN-tjänster. Private Internet Access (PIA) med bl.a. Rick Falkvinge kommer att betala för en oberoende granskning av OpenVPN som leds av kryptologen Dr. Matthew Green. Matthew hade tidigare hand om den öppna granskningen av TrueCrypt. PIA är ett företag som tillhandahåller VPN-anslutningar och som använder OpenVPN

OpenVPN har funnits sedan 2001 och använder en variant på SSL/TLS som kanal för kommunikation och går att köra på operativsystem såsom Solaris, Linux, OpenBSD, FreeBSD, NetBSD, QNX, Mac OS X, iOS, Android och Windows från version XP.

PIA meddelar att efter granskningen är klar och OpenVPN åtgärdat eventuella brister så kommer rapporten att publiceras på deras hemsida.

Senast en sårbarhet uppdagades i OpenVPN var under 2016 då födelsedags-attacken Sweet32 som går mot 64-bits algoritmer såsom den som OpenVPN använder som standard, BF-CBC.

Och viktigt att notera är att OpenVPN används på både klienten och servern. Ett alternativ till OpenVPN är att köra stunnel eller IPSEC.

Uppdatering: Under tiden jag skrev denna artikel har två andra relaterade nyheter dykt upp:

  • Algo lyfts upp som ett nytt alternativ till IPSec och OpenVPN
  • OSTIF meddelar att de anlitar Quarks Lab för att också granska OpenVPN. Samma franska företag som tidigare granskade VeraCrypt

Faktorisera 512 bitar RSA SSL/TLS

Nyligen så uppdagades en ny attack mot SSL/TLS vid namn SMACK. Denna attack nyttjar det faktum att många webbsajter i dagsläget erbjuder gamla krypteringsalgoritmer där bl.a. RSA 512 bitar finns med samt en sårbarhet i klienter.

Att faktorisera 512 bitar RSA går relativt snabbt med hjälp av ett kluster hos exempelvis Amazon EC2. Och med hjälp av 75 st servrar hos Amazon tar det cirka 7h och kostar runt 800 SEK. Och verktyget som användes för detta är bl.a. cado-nfs (eller så kan även ggnfs + msieve användas).

Men hur utbrett är problemet eg. med dessa korta nyckellängder på serversidan? Jo, av 14 miljoner sajter som stödjer SSL/TLS så har 36.7% detta problem. Och problemet i detalj består i att om en klient såsom OpenSSL eller Apples SecureTransport får tillbaka ett svar som inkluderar export-grade RSA så kommer dessa klienter att acceptera svaret, även om de ej frågat efter export-grade RSA.

Förfarandet steg för steg:

  1. När klienten skickar sitt Hello-meddelande så frågar den efter standard RSA
  2. Angripare som sitter i mitten (MITM) ändrar detta svar till export RSA
  3. Servern svarar med sin 512-bitars export RSA-nyckel, signerad med sin nyckel för långa livslängder (long term key).
  4. Klienten sväljer detta svar på grund av OpenSSL/SecureTransport-buggen.
  5. Angriparen faktoriserar RSA för att hitta den privata nyckeln
  6. När klienter krypterar ‘pre-master secret’ till servern så kan nu angriparen dekryptera TLS huvudhemlighet (master secret)
  7. Nu kan angriparen se klartext och injicera nytt innehåll

Demonstration av hur attacken kan nyttjas mot NSA (eller rättare skrivet, Akamai):

nsa-fake copy

Snabbare https med SSL False Start

De smarta utvecklarna i Google Chrome teamet har skickat in en draft till IETF som beskriver en metod att snabba upp surfandet på krypterade https-sidor med hjälp av modifiering i SSL/TLS-protokollet.

Denna modifiering har fått namnet False Start av Google för att reflektera ändringarna som föreslagits i handskakningen. Googles tester visar på en ökning av hastigheten på upp till 30%.

IETF Draften kan hittas här: tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

Källa: Chrome Blog