Recommended Posts

HTTP/2 skådat!  B)

 

Twitter använder det nya protokollet, upptäckte jag nyss, se bild (Chrome 37.0.2041.4 Dev).

 

post-7701-0-75237500-1402577070.png

 

”h2-12” står för HTTP/2 utkast 12.

 

I Chromium 36 (Revision 263664) aktiverades stöd för HTTP/2 (SPDY/4), och i Chromium 37 (Revision 271554) uppdaterades stödet från utkast 11 till utkast 12.

 

Chrome-tillägget SPDY indicator visar om SPDY (grön blixt + versionsnummer), QUIC (röd blixt) eller HTTP/2 (blå blixt) används.

 

post-7701-0-45905400-1402577674.png

Länk till inlägg
Dela på andra webbplatser
  • Svar 53
  • Created
  • Senaste svar

Nytt i utkast 13, som ännu ej har publicerats, är att chiffersviter som använder ”stream or block ciphers” inte tillåts. AEAD-chiffersviter är ”acceptabla”. AES_GCM och CHACHA20_POLY1305 är således acceptabla, medan AES_CBC, RC4 och 3DES inte är det. AES_GCM förutsätter TLS 1.2, som redan är ett krav för HTTP/2-implementeringar¹. Dessutom tillåts endast efemärt nyckelutbyte, vilket innebär att endast nyckelutbytesmekanismer som stöder framåtsekretess, såsom DHE_RSA, ECDHE_RSA, ECDHE_ECDSA tillåts.

 

Det senaste utkastet finns här: https://http2.github.io/http2-spec/

Se även: https://github.com/http2/http2-spec/issues/491

 

Begränsningen av chiffersviter överensstämmer med det kommande kryptografiska protokollet TLS 1.3².

 

¹ https://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-9.2

² https://tools.ietf.org/html/draft-ietf-tls-rfc5246-bis-00

Länk till inlägg
Dela på andra webbplatser

Va, har du inte läst allt jag har skrivit om detta i olika trådar? :)

 

En chiffersvit (Cipher suite) är de algoritmer som används för kryptering och verifiering/autentisering. I oktober 2011 blev det känt att AES_CBC var sårbart för den s.k. BEAST-attacken, se t.ex. Mitigating the BEAST attack on TLS. Rekommendationen var då att ersätta AES_CBC med RC4. BEAST är (eller var) ett problem med TLS 1.0, men inte med TLS 1.1, 1.2. Vid den tiden var dock stödet för TLS 1.1 och 1.2 ytterst begränsat på både server- och klientsida, och där det fanns (IE, Opera) var det inaktiverat som standard. RC4 var därför den mest praktiska lösningen på BEAST-problemet. I mars 2013 visade det sig dock att RC4 är mycket mer sårbart än man tidigare var medveten om: RC4 in TLS is Broken: Now What? Då BEAST inte längre är ett problem, förutsatt att uppdaterade implementeringar används (Is BEAST Still a Threat?), var återgång till AES_CBC ett sätt att lösa RC4-problemet. En bättre lösning är dock att använda en chiffersvit utan kända svagheter, och en sådan är AES_GCM, som ingår i TLS 1.2-specifikationen. Alla aktuella webbläsare stöder TLS 1.2, och bland de mer använda webbläsarna är det endast Safari som ännu inte stöder AES_GCM (förhoppnings- och troligtvis ändras det i höst, då Safari 8 släpps). Även CHACHA20_POLY1305 är utan kända svagheter, men stöds för närvarande endast av Chromium, och används på Googles servrar.

 

Det är således positivt att sårbara chiffersviter helt utestängs från HTTP/2 (och TLS 1.3).

 

Angående nyckelutbytesmekanismer är det av vikt att krypterad information inte kan avkodas av den som vid ett senare tillfälle kommer över den privata krypteringsnyckeln. Det är kortfattat vad framåtsekretess (Forward secrecy) handlar om, och i HTTP/2-specifikationen tillåts endast nyckelutbytesmekanismer som stöder framåtsekretess, såsom DHE_RSA, ECDHE_RSA, ECDHE_ECDSA. Den viktiga bokstaven där är E i (EC)DHE: E för ephemeral ’efemär’, se Ephemeral key. RSA som nyckelutbytesmekanism erbjuder däremot ej framåtsekretess.

 

HTTP/2 kommer således att innebära en på flera sätt förbättrad säkerhet. Något som har diskuterats men inte inkluderats i HTTP/2-specifikationen är obligatorisk kryptering. Däremot kommer vissa implementeringar endast att använda HTTT/2 över TLS, se Does HTTP/2 require encryption?

 

En annan intressant nyhet handlar om opportunistisk kryptering, som innebär att kryptering används där den är tillgänglig, även om adressen innehåller http och inte https. Beskrivs i Opportunistic Encryption for HTTP URIs (senaste här). Status för detta förslag är ”agreed to adopt as WG Experimental.”

Länk till inlägg
Dela på andra webbplatser
  • 1 month later...
  • 3 weeks later...

Microsoft har sedan några dagar en HTTP/2-serverimplementering (prototyp), baserad på utkast 14 (h2-14).

 

Microsoft HTTP 2 Prototype (GitHub)

 

Nu kan implementeringen testas med Chrome 39 (Canary), vars HTTP/2-implementering nu stöder utkast 14: https://h2duo.cloudapp.net/

 

Vill man testa med en Microsoft-klient får man kontakta Microsoft (adress på GitHub-sidan).

 

Även Firefox Nightly stöder h2-14.

 

post-7701-0-88698900-1408777046.png

 

Det är f.ö. den första Microsoft-sida jag har sett som använder AES_GCM. Microsoft föredrar annars AES_CBC, men HTTP/2 tillåter endast AEAD-chiffersviter (som AES_GCM och CHACHA20_POLY1305).

 

Även Twitter använder h2-14 för kompatibla klienter: https://twitter.com/

Länk till inlägg
Dela på andra webbplatser
  • 2 weeks later...

h2-14 är aktiverat på google.com.

 

post-7701-0-84692600-1409730439.png

 

Statusrapport för HTTP/2 i Chrome:

HTTP/2.0 a.k.a SPDY 
Current Status: 
Spec updates have slowed down as it prepares to enter last call. The last IETF saw concerns raised from carriers and other interested parties on the increase of encrypted traffic overall on the web. They worry that HTTP/2 will accelerate this trend. In Chrome, we are aiming to get HTTP2 draft 14 support in M39, and recent Chrome canary builds support this when the “Enable SPDY/4” flag is turned on via about:flags.

 

Länk till inlägg
Dela på andra webbplatser
  • 5 weeks later...

Internet Explorer i Windows 10 stöder HTTP/2.

 

IEBlog: Internet Explorer and the Windows 10 Technical Preview

 

I Chrome kommer användningen av h2-14 (HTTP/2 utkast 14) att öka när Chrome 39 snart når betakanalen, och avsikten är att det skall vara aktiverat som standard då M39 når den stabila kanalen. M38, som nu är i betakanalen stöder endast h2-13.

 

PSA: Chromium ramping up h2-14 support.

Länk till inlägg
Dela på andra webbplatser

Som sägs i förra inlägget, använder Chrome 39 beta HTTP/2 (h2-14) när det är tillgängligt. Bilden visar chrome://net-internals/#spdy vid anslutning till https://encrypted.google.com/ och https://h2duo.cloudapp.net/ 

 

post-7701-0-81188700-1412963643_thumb.pn

 

Under Alternative Protocol Mappings listas de värdar som använder det UDP-baserade protokollet QUIC.

 

post-7701-0-91540400-1412964038.png

 

Twitter har tidigare använt de olika HTTP/2-utkasten (senast h2-14), men för närvarande erbjuds endast SPDY/3.1 och HTTP/1.1.

Länk till inlägg
Dela på andra webbplatser

I ett tidigare inlägg gav jag exempel på sidor som använder SPDY. Här kommer exempel på sidor som använder HTTP/2 (h2-14). Listan skulle kunna göras lång genom att ta med alla *.google.com-domärner, och alla lokala Google-domäner, som *.google.se, men det vore inte så meningsfullt, så jag tar endast med några få Google-domäner.

CloudFlare är på gång med HTTP/2 (de använder nu SPDY/3.1): ”and we’ll support HTTP/2 just as soon as it is practical”. När det sker kommer ett par miljoner sidor att distribueras över HTTP/2.

 

Webbläsare som stöder h2-14 är Chrome 39+, Opera 26+, Firefox 34+, IE i Windows 10. Alla använder HTTP/2 endast över TLS, alternativt QUIC (Chromium).

Länk till inlägg
Dela på andra webbplatser
  • 3 weeks later...

Utkast 15, daterat 27 oktober: https://tools.ietf.org/html/draft-ietf-httpbis-http2-15

 

Ändringslogg: https://tools.ietf.org/html/draft-ietf-httpbis-http2-15#appendix-A.1

 

 

Endast en fråga kvar att lösa: https://github.com/http2/http2-spec/issues

 

Den handlar om avdelningen 9.2.2 TLS Cipher Suites

 

Diskussionen kan följas i e-postlistan.

 

Alla HTTP/2-implementeringar måste stödja TLS 1.2, men i HTTP/2 vill man endast tillåta chiffersviter med efemära nyckelutbytesmekanismer som DHE och ECDHE, och både ström- och blockchiffer (såsom RC4 resp. AES-CBC). Kvar är Authenticated Encryption with Additional Data (AEAD), t.ex. AES-GCM och ChaCha20+Poly1305.

 

Bäst vore om man kunde kräva stöd för TLS 1.3, som uppfyller dessa krav, men den specifikationen har väl ett år kvar till att bli färdig, medan HTTP/2 i stort är klar. Ett förslag går ut på att påskynda utvecklingen av TLS 1.3 genom att tillämpa HTTP/2-kraven på TLS 1.2-specifikationen (ta bort oönskade chiffersviter), och skjuta upp övriga förändringar till TLS 1.4.

Länk till inlägg
Dela på andra webbplatser
  • 3 weeks later...

Googles servrar stöder nu h2-15 istället för h2-14.

 

Chromium fick stöd för h2-15 (istället för h2-14) den 7 november: https://chromium.googlesource.com/chromium/src/+/6371af94b25f78f85691e892627a9e88832e2ba0

 

För att använda HTTP/2 vid anslutning till Googles servrar behöver man Chrome Dev/Canary 40.0.2214.5+.

Länk till inlägg
Dela på andra webbplatser
  • 2 weeks later...

Utkast 16: https://tools.ietf.org/html/draft-ietf-httpbis-http2-16

 

Ändringslogg: https://tools.ietf.org/html/draft-ietf-httpbis-http2-16#appendix-B

 

Inga öppna problem nu: https://github.com/http2/http2-spec/issues

 

Google har gått tillbaka till h2-14 på sina servrar, vilket innebär att Chrome 39+ och Firefox 34+ kan ansluta till dem via HTTP/2. Twitter stöder för närvarade h2-15.

Länk till inlägg
Dela på andra webbplatser
  • 2 months later...

Mark Nottingham: HTTP/2 is Done  :D

 

I går upptäckte jag att Wikimedia har aktiverat SPDY/3.1. Tiden för SPDY/3.1 är utmätt, så det är väl mest som en förberedelse för HTTP/2. Det kommer dock att tid innan stabila versioner av de flesta webbläsare kommer att stödja den skarpa versionen av HTTP/2. Chromium och Safari hänger nog på låset, medan IE-användare får invänta Windows 10. Chrome kommer också att stödja SPDY/3.1 ytterligare ett år.

Länk till inlägg
Dela på andra webbplatser
  • 4 weeks later...
Chrome Dev 43.0.2334.0 stöder h2 (och h2-14).

 

Stöd för h2, d.v.s. den skarpa versionen av HTTP/2, lades till i Chromium den 9 mars¹.

 

post-7701-0-56846800-1426658284_thumb.pn

 

Några sidor som använder h2:






 

HTTP/2 and SPDY indicator är ett Chrome-tillägg som visar om HTTP/2, SPDY eller QUIC används. Ett klick på tilläggets ikon i adressfältet öppnar chrome://net-internals/#spdy (se bild) respektive chrome://net-internals/#quic.

 


 

Uppdatering: Googles servrar stöder h2.

Länk till inlägg
Dela på andra webbplatser
  • 1 month later...
  • 2 months later...

I och med att Windows 10 släpptes för två veckor sedan, tillkom två webbläsare som stöder HTTP/2: Edge och Internet Explorer. Testsida: https://http2.akamai.com/

 

På serversidan ökar användningen av HTTP/2: https://w3techs.com/technologies/details/ce-http2/all/all

 

Också SPDY, som har några års försprång, ökar: https://w3techs.com/technologies/details/ce-spdy/all/all

Länk till inlägg
Dela på andra webbplatser
  • 2 months later...

HTTP/2-användningen är nu uppe i 2 %. Användningen av SPDY minskar.

 

Comparison of the usage of SPDY vs. HTTP/2 for websites (W³Techs)

 

Nyligen har Yahoo! uppgraderat till HTTP/2, t.ex. på söksidan: https://se.search.yahoo.com och Yahoo! Mail.

 

WordPress.com  och WordPress.org använder HTTP/2, liksom VideoLAN.

 

Wikimedia och Facebook har ännu inte uppgraderat från SPDY till HTTP/2.

 

CloudFlare är  på gång, och har en HTTP/2-spegel av bloggen: Test all the things: IPv6, HTTP/2, SHA-2

Länk till inlägg
Dela på andra webbplatser
  • 4 weeks later...

CloudFlare är  på gång, och har en HTTP/2-spegel av bloggen: Test all the things: IPv6, HTTP/2, SHA-2

De har nu tagit ett halvt steg framåt. Vissa sidor som distribueras av CloudFlare använder nu HTTP/2, medan andra ännu använder SPDY/3.1.

 

Exempel på HTTP/2, då jag besöker sidorna: https://blog.cloudflare.com/, https://istlsfastyet.com/ och https://shutthebackdoor.net/

 

Exempel på SPDY/3.1, då jag besöker sidorna: https://www.cloudflare.com/ (nu HTTP/2), https://www.resetthenet.org/ och https://feedly.com/

 

Det finns ett tillägg för Chrome, som visar om sidan distribueras av CloudFlare, och vilket protokoll som används, vilken server man är ansluten till m.m.

Länk till inlägg
Dela på andra webbplatser

Arkiverat

Detta ämne är nu arkiverat och det går inte längre svara i det.


  • Liknande innehåll

    • Av JoWa
      I maj 2015 blev HTTP/2 (RFC 7540) klart, och nu arbetas det på HTTP/3.
      Tekniskt sett har arbetet pågått i flera år redan, men först den 18 december i år publicerades det första utkastet kallat Hypertext Transfer Protocol Version 3 (HTTP/3).
      Detta utkast, som har nummer 17, föregicks av utkast kallade Hypertext Transfer Protocol (HTTP) over QUIC. Och där har vi en beskrivning av HTTP/3. Det är HTTP över QUIC, något som redan används av Google och Cloudflare, och stöds av Chromium. HTTP/3 säkras med TLS 1.3, eller med nyare TLS-versioner i framtiden. Redan dagens implementeringar av QUIC använder TLS 1.3.
      QUIC, Quick UDP Internet Connections, är ett protokoll som först utvecklades av Google. De skrev första gången om det i juni 2013. UDP är User Datagram Protocol, som används i stället för TCP, Transmission Control Protocol, som annars används med HTTP.
      Utkast till specifikationer:
      Hypertext Transfer Protocol Version 3 (HTTP/3) QUIC: A UDP-Based Multiplexed and Secure Transport Using TLS to Secure QUIC Daniel Stenberg: HTTP/3
      Wikipedia: HTTP/3
    • Av JoWa
      Förra veckan presenterade Wikimedia Foundation sina planer för förbättrad säkerhet vid anslutning till något av Wikimedia-projekten (Wikipedia, Wiktionary m.fl.):
      The future of HTTPS on Wikimedia projects
      Wikimedia-projekten har varit tillgängliga via HTTPS sedan 2011: Native HTTPS support enabled for all Wikimedia Foundation wikis
      Nu höjer de säkerhetsnivån genom att steg för steg se till att HTTPS används som standard. Att det görs stegvis beror på att deras nuvarande arkitektur inte kan hantera HTTPS som standard för alla. De börjar därför med inloggningen och inloggade användare.
      Tills HTTPS är aktiverat som standard på alla Wikimedia-sidor, rekommenderar Wikimedia att man använder HTTPS Everywhere (Chrome, Firefox; fungerar även med Opera 15+).
      En förbättring som inte nämns i bloggen är det förbättrade stödet för kryptografiska protokoll. Nu stöds den senaste och säkraste protokollversionen, TLS 1.2, mot tidigare TLS 1.0 som bästa protokoll ([Wikitech-l] no TLS 1.1 and 1.2 support).
      Dagen innan Wikimedia publicerade sina planer, presenterade Facebook sina ambitiösa planer för bättre säkerhet: Secure browsing by default 
      Detta efter att ha erbjudit HTTPS som alternativ sedan början av 2011: A Continued Commitment to Security
      Vidare kan nämnas att Myspace nu använder HTTPS som standard: https://myspace.com/
      Att Yahoo! Mail i början av 2013 gjorde HTTPS användbart för hela sessionen (inte bara inloggning och kontohantering) har tidigare rapporterats: Yahoo! Mail och SSL/TLS
      En del av Googles sedan länge pågående arbete med att förbättra säkerheten har också rapporterats: Krypterad Google-sökning
      Sammanfattningsvis kan sägas att 2013 ser ut att bli ett bra år för kryptering på Internet. Men samtidigt dyker Breach upp.
    • Av JoWa
      Secure Sockets Layer (SSL) utvecklades av Netscape, och lanserades (version 2.0) i februari 1995. SSL uppdaterades till version 3.0 1996. SSL är ett kryptografiskt protokoll som används för att skapa säkra (krypterade) förbindelser över Internet.
      Utvecklingen gick vidare, och SSL fick en efterträdare i Transport Layer Security (TLS). Version 1.0 av TLS lanserades i januari 1999, följd av TLS 1.1 (april 2006) och TLS 1.2 (april 2008).
      Alla dessa versioner kan ännu användas, men SSL 2.0 är en mycket osäker version, och väldigt får servrar stöder SSL 2.0. I ingen av dagens webbläsare är SSL 2.0 aktiverat, och endast Internet Explorer (t.o.m. version 10) har möjlighet att aktivera den osäkra protokollversionen.
      TLS 1.0 är den mest använda protokollversionen. Alla (?) servrar stöder den, och alla webbläsare har sedan länge stöd för TLS 1.0 aktiverat som standard.
      Internet Explorer i Windows 7 och 8 stöder även TLS 1.1 och 1.2, men dessa versioner är inte aktiverade som standard. För att aktivera, öppna Internetalternativ, fliken Avancerat, rubriken Säkerhet. Markera ”Använd TLS 1.1” och ”Använd TLS 1.2”. Markera inte ”Använd SSL 2.0”.

      Opera stöder även TLS 1. 1 och 1.2, men det är inte heller där aktiverat som standard. För att aktivera, gå till Inställningar, Avancerat, Säkerhet, Säkerhetsprotokoll.

      Eller skriv opera:config i adressfältet, tryck Retur. Skriv ”tls” i sökrutan och markera ”Enable TLS v1.1” och ”Enable TLS v1.2”.

      Firefox och Chrome använder Network Security Services (NSS), som stöder upp till TLS 1.1. I Chrome är TLS 1.1 aktiverat som standard, medan Firefox ännu (v. 18) endast stöder SSL 3.0 och TLS 1.0.
      I Opera och Chrome kan man lätt se vilket krypteringsprotokoll som används, se bifogade bilder.

      Läsning:
      Wikipedia: Transport Layer Security
      Wikipedia: Network Security Services
      Adam Langley (Google): New TLS versions
    • Av JoWa
      Att en kommande version av Internet Explorer skall stödja HTTP Strict Transport Security (HSTS) har varit känt en tid, bl.a. genom https://status.modern.ie/httpstricttransportsecurityhsts?term=hsts
       
      Nyligen publicerades ett inlägg på IEBlog som bekräftar stöd för HSTS i IE och senare Project Spartan i Windows 10: 
      HTTP Strict Transport Security comes to Internet Explorer Inte fem år för tidigt, men bättre sent än aldrig.
       
      IEBlog bekräftar även att Googles förladdningslista, med för närvarande drygt 1 500 förladdade domäner med läget force-https, används. Denna ”förladdning” (preload) av domäner är mycket värdefull, HSTS lämnar den allra första anslutningen till en HSTS-domän sårbar.¹ Det är nämligen först efter att en säker anslutning till en HSTS-domän har gjorts som webbläsaren vet att den endast skall ansluta säkert till den domänen i fortsättningen, under den tid som är angiven i HSTS-headern, och vanligen 180 dagar eller längre. Twitter har tagit i ordentligt, med hela 7 304 dagar (20 år).²
       
      ¹ https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#Limitations
      ² https://spdycheck.org/#twitter.com
    • Av JoWa
      Önskemål: säker anslutning till alltomwindows.se
       
      Nu för tiden anses all information vara ”känslig”, och målet är att varje anslutning så snart som möjligt skall vara säker. Därmed finns det anledning att erbjuda säker anslutning för alla som besöker alltomwindows.se. Dock är viss information mer känslig än annan, och dit hör förstås inloggningsuppgifter och privata meddelanden, samt information i forumets interna avdelningar.
       
      I Firefox 46, som nu är beta, märks osäkra anslutningar som osäkra (överstruket hänglås) om sidan innehåller ett inloggningsformulär: Login Forms over HTTPS, Please
       
      Att märka osäkra anslutningar som osäkra (oavsett sidans innehåll) är under utvärdering för Chrome: Marking HTTP As Non-Secure
       
      Vad jag kan se, är det Amazon som hyser AoW, och där kan man få ett certifikat gratis. Certifikatet förnyas också automatiskt.
    • Av JoWa
      EFF har publicerat två artiklar om Superfish, det annonsprogram som Lenovo har installerat på sina datorer.
      Lenovo Is Breaking HTTPS Security on its Recent Laptops How to Remove Superfish Adware From Your Lenovo Computer En testsida gjord av Filippo Valsorda, som visar om Superfish är aktivt: https://filippo.io/Badfish/
       
      Lenovos ynkliga kommentar (som helt förtiger själva problemet): LENOVO STATEMENT ON SUPERFISH