Recommended Posts

Vad menar du med ”omförhandla en https anslu[t]ning till en http om det skulle behövas”? Kan du ge något exempel? En sådan situation skulle t.ex. kunna uppstå om man aktiverar de experimentella reglerna i tillägget HTTPS Everywhere. Annars är det alltid HTTP webbläsare använder.

HSTS, som länkat inlägg handlar om, stöds inte av IE, så det är inte förklaringen. De få sidor som använder HSTS torde fungera utmärkt via HTTPS.

Edited by JoWa
Link to comment
Share on other sites

Är inte så väldigt insatt i det här, men det är nog så att vissa servrar inte accepterar https anslutning, däremot går det bra med http för samma sida.

Exempel på det kan vara wikipedia tex.. Har alltså bollat med olika inställningar och testade på skoj med IE.

Klickar jag på en https länk fungerar det alltså inte,, men samma sida fungerar utmärkt med http. Därför verkar det vara som om
webbläsarna-servern försöker att forcera https anslutning utan att http "går in".

Däremot fungerar det att koppla upp sig mot en bank utan problem, och håller på och testar HTTP Nowhere just nu.

Link to comment
Share on other sites

Hm, Wikipedia (och övriga Wikimedia-projekt) fungerar utmärkt via HTTPS, som också används som standard för inloggade användare.

Om t.ex. https://sv.wikipedia.org/wiki/Portal:Huvudsida och https://sv.wiktionary.org/wiki/Wiktionary:Huvudsida inte öppnas är något på tok hos dig.

Edited by JoWa
Link to comment
Share on other sites

  • 1 month later...

IEBlog om att TLS 1.2 är aktiverat som standard i IE11: 

IE11 Automatically Makes Over 40% of the Web More Secure While Making Sure Sites Continue to Work

Första meningen – ”Internet Explorer 11 is the first browser to make Internet connections more secure and reliable by reducing the use of vulnerable ciphersuites, such as RC4 and by using the latest security standards, TLS 1.2, by default.” – stämmer väl inte helt. Chrome (stabil) har använt TLS 1.2 sedan augusti, och föredrar AES GCM (som förutsätter TLS 1.2), AES CBC, och använder endast vid avsaknad av dessa RC4.

Anmärkningen till trots, är det en betydande förbättring av IE, och utfasningen av RC4 kan nu påskyndas. :)

Även i Safari 7 (OS X 10.9) är TLS 1.2 aktiverat: Apple Enabled BEAST Mitigations in OS X 10.9 Mavericks

Relaterat: A roster of TLS cipher suites weaknesses

Edited by JoWa
Link to comment
Share on other sites

  • 4 weeks later...
  • 4 weeks later...

2013 innebar ett genombrott för TLS 1.2. :)

 

Då jag i januari 2013 startade tråden, stöddes TLS 1.2 och 1.1 av Internet Explorer 8+ (Windows 7) och Opera, men i både IE och Opera var sagda protokoll inaktiverade som standard. Chrome stödde TLS 1.1 (aktiverat), men inte TLS 1.2. Safari (iOS) hade TLS 1.2 aktiverat.

Sedan började det att röra på sig. Den öppna TLS-implementeringen Network Security Services (NSS), som används i Firefox och Chromium, fick stöd för TLS 1.2 i och med version 3.15.1 den 1 juli. Stöd för TLS 1.1 infördes med version 3.14. Med stöd för TLS 1.2 i NSS på plats, kunde stöd läggas till i Chrome 29 (20 augusti) och Opera 16 (27 augusti).

Internet Explorer 11 lanserades med Windows 8.1 den 17 oktober, och släpptes för Windows 7 den 7 november och har TLS 1.2 och 1.1 aktiverade som standard.

Safari 7 (OS X 10.9) med aktiverat stöd för TLS 1.2 och 1.1 släpptes den 22 oktober. Safari 7 stöder dock för närvarande inte AES_GCM.

Sist ut av de stora webbläsarna är Firefox, vars stabila version ännu inte har aktiverat stöd för TLS 1.2 och 1.1. Firefox 27, som nu är beta, har aktiverat stöd för TLS 1.2 och 1.1, och kommer att släppas som stabil den 4 februari.

Även på serversidan har det hänt en hel del. I januari 2013 stödde 11,4 % av 177 391 undersökta webbsidor¹ TLS 1.2. I januari 2014 stödde 25,7 % av 160 046 undersökta webbsidor TLS 1.2. För första gången stöder nu större andel TLS 1.2 än det gamla och mycket osäkra protokollet SSL 2 (som nästan inga webbläsare stöder). Källa: SSL Pulse

Många av de riktigt stora webbsidorna har under 2013 aktiverat TLS 1.2, t.ex. Wikipedia och övriga Wikimedia-projekt, Facebook, Twitter, Dropbox, Ubuntu One, Apple, Yahoo!. Google aktiverade TLS 1.2 redan 2012. Microsoft ligger efter och stöder som bäst TLS 1.0. https://www.bing.com/ använder förvisso TLS 1.2, men för mig saknar sidan allt innehåll. (Uppdatering: Microsoft använder TLS 1.2 på sina sidor, och Bing fungerar förstås över TLS.)

Även om denna tråd primärt handlar om krypteringsprotokoll, är det fler saker som bestämmer säkerhetsnivån. Valet av chiffersvit är också avgörande. T.ex. använder både Google och Yahoo! TLS 1.2, men medan Google använder den säkra och ”framåthemliga” chiffersviten TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (t.ex. med Chrome), använder Yahoo! TLS_RSA_WITH_RC4_128_SHA, som trots lika stark kryptering (128-bit) har flera svagheter, inte minst RC4 som anses vara mycket osäkert, RSA som mekanism för nyckelutbyte är inte ”framåthemligt”, för meddelandeautentisering används SHA1, som anses vara en svag algoritm (det finns dock sidor som använder MD5!).

Dock skall inte krypteringsprotokollets roll underdrivas. Den enda allmänt använda chiffersvit som inte har några kända svagheter är AES_GCM, som endast kan användas med TLS 1.2. AES_CBC i kombination med TLS 1.0 är sårbart för BEAST-attacken, men inte i kombination med TLS 1.1, 1.2.

¹ Det är vettigare att tala om antal webbsidor än antal servrar, då en webbsida i förekommande fall kan kommas åt via ett stort antal identiskt konfigurerade servrar.

Edited by JoWa
Link to comment
Share on other sites

  • 2 months later...
  • 1 month later...
On 2014-01-08 at 09:36, JoWa sade:

I januari 2013 stödde 11,4 % av 177 391 undersökta webbsidor¹ TLS 1.2. I januari 2014 stödde 25,7 % av 160 046 undersökta webbsidor TLS 1.2. För första gången stöder nu större andel TLS 1.2 än det gamla och mycket osäkra protokollet SSL 2 (som nästan inga webbläsare stöder). Källa: SSL Pulse

Och i maj 2014 stöder 35,8 % (+ 10,1 procentenheter sedan januari) av 156 022 webbsidor TLS 1.2 och 33,1 % stöder TLS 1.1. :)

Standardwebbläsaren i äldre Android-versioner (t.o.m. 4.3) stöder endast TLS 1.0. Först i Android 4.4 stöder standardwebbläsaren TLS 1.2. För användare av äldre versioner finns det således anledning (ja, många faktiskt) att använda en alternativ (och modern) webbläsare. 

För Android 2.2+ finns t.ex. Firefox. För Android 4.0+ finns t.ex. Chrome och Opera.

Edited by JoWa
Link to comment
Share on other sites

  • 1 month later...

IE11 på Windows Phone 8.1 stöder TLS 1.1 och 1.2: https://www.ssllabs.com/ssltest/viewClient.html?name=IE%20Mobile&version=11&platform=Win%20Phone%208.1

Jag hade dock gärna sett TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 på första plats bland stödda chiffersviter. I listans topp finner man istället svagare chiffersviter, utan framåtsekretess.

Edited by JoWa
Link to comment
Share on other sites

Vill bara varna för att det kan ställa till problem så länge TLS 1.1 och 1.2 är aktiverat då vissa (äldre) webbservrar och applikationsservrar inte kan hantera den kombinationen och ger "sidan kan inte visas", åtminstone i Internet Explorer 11. Har inte verifierat om problemet gäller även andra webbläsare.

 

Lösningen i IE11 är att via Group policies ställa in att endast köra SSLv3 och TLS1.0.

Link to comment
Share on other sites

Har du något exempel på problemsida?

Tycker att det låter konstigt. I IE11, liksom i aktuella versioner av Chrome, Firefox, Opera och Safari, är SSL 3, TLS 1.0, 1.1, 1.2 aktiverade som standard. Att TLS 1.1 och 1.2 är aktiverade hindrar inte anslutning till en server som endast erbjuder TLS 1.0 och/eller SSL 3, om inte användaren/administratören inaktiverar de sistnämnda protokollen.

SSL 3 stöter jag aldrig på nu för tiden (annat än som alternativ till säkrare protokoll). Senast jag såg det använt var på https://archive.org/ som nu erbjuder TLS 1.2.

Edited by JoWa
Link to comment
Share on other sites

Har du något exempel på problemsida?

 

Har dessvärre inget exempel på en publik webbsida som har problemet. Håller med om att det låter konstigt men endast genom att forcera IE11 till SSLv3 eller TLS1.0 (eller båda) fungerade det. Jag gick inte till botten med problemet utan konstaterade att det fungerade om man stängde av TLS1.1 och 1.2.

 

http://blogs.technet.com/b/iede/archive/2010/09/27/as-59-63-ssl-2-0-ssl-3-0-tls-1-0-tls-1-1-tls-1-2-verwenden.aspx

Värdena i ovanstående blogginlägget var guld värda vid felsökningen :)

Link to comment
Share on other sites

Aha, interna sidor. Då föreslår jag ett ”allvarligt” samtal med de ansvariga.  B)

De gamla och osäkra protokollen bör fasas ut omedelbums. Det är också dags för administratörer att förbereda sig för HTTP/2, där TLS 1.2 är obligatoriskt att implementera och endast AEAD-chiffersviter accepteras, vilket utesluter äldre protokoll (även TLS 1.1).

Edited by JoWa
Link to comment
Share on other sites

Hur gör man med Mozilla produkter om det dyker upp webbsida som "talar om" att man måste aktivera SSL ?
Gå via about:config ?
(security.tls.version.min/max på 0 resp. 3) Har default inställningar annars.

Kör med Pale Moon för tillfället, det kom en uppdatering igår (om det har med det att göra ?).


Testade med IE9 som fungerade klockrent, men däremot rekommenderade webbsidan Firefox som vad jag förstår har samma inställningar per default. :blink:

 

Edit : Hittade "felet",, ställde om "Certifikatsökningen till automatisk", den stod på "Fråga mig varje gång ".

Edited by plastiq
Link to comment
Share on other sites

  • 3 months later...

Det har nu framkommit att SSL3 är sårbart för ”pudelattacken”. Det är med andra ord hög tid att skrota det föråldrade krypteringsprotokollet. CloudFlare har inaktiverat det på sina servrar, vilket påverkar ett par miljoner webbsidor. Även Facebook, Twitter och LinkedIn har inaktiverat SSL3. Problemet med det är förstås att det förekommer gamla webbläsare, som IE6. IE6 stöder TLS 1.0, men det är inaktiverat som standard. IE6-användningen är dock endast 0,24 % enligt StatCounter. Google använder TLS Fallback SCSV, som förhindrar nedgradering från TLS 1.2 till SSL3 (och TLS 1.1, 1.0), om webbläsaren stöder det.

Edited by JoWa
Link to comment
Share on other sites

 

Det har nu framkommit att SSL3 är sårbart för ”pudelattacken”. Det är med andra ord hög tid att skrota det föråldrade krypteringsprotokollet. CloudFlare har inaktiverat det på sina servrar, vilket påverkar ett par miljoner webbsidor. Även Facebook, Twitter och LinkedIn har inaktiverat SSL3. Problemet med det är förstås att det förekommer gamla webbläsare, som IE6. IE6 stöder TLS 1.0, men det är inaktiverat som standard. IE6-användningen är dock endast 0,24 % enligt StatCounter. Google använder TLS Fallback SCSV, som förhindrar nedgradering från TLS 1.2 till SSL3 (och TLS 1.1, 1.0), om webbläsaren stöder det.

 

 

Stäng av SSL3 för att skydda dig.

 

I samtliga Chrome-varianter...

Starta chrome.exe med parametern "--ssl-version-min=tls1"

 

I samtliga Firefox-varianter...

Gå till about:config och sätt värdet "security.tls.version.min" till 1

 

I Internet Explorer...

Gå till Internetalternativ/Avancerat och bocka av "Använd SSL 3.0"

  • Like 1
Link to comment
Share on other sites

On 2014-10-16 at 07:38, JoWa sade:

Instruktioner för Opera 12 finns i första inlägget i denna tråd.

Opera har ändrat inställningarna för TLS/SSL i Opera 12.

Citat
Finally, Opera 12 on desktop is taking the lead with disabling SSLv3 support! Since we are not able to apply the countermeasure to all of the remaining Opera 12 installations (and it also does not support TLS_FALLBACK_SCSV), we have remotely turned off SSLv3. This will be automatically distributed to all Opera 12 desktop installations in the next few days. We’re allowing ourselves to be a bit experimental with this, so users who have not yet upgraded to Opera 25 may see more of the broken servers, and we will get some experience in turning off SSLv3. Opera Classic on Android will also be updated in the next coming days.

https://www.opera.com/blogs/security/2014/10/security-changes-opera-25-poodle-attacks/

Samtidigt aktiverades TLS 1.1 och 1.2. Opera 12 stöder dock inte AES_GCM, som annars är en av de stora fördelarna med TLS 1.2.

Trots de förbättrade inställningarna är det hög tid att överge Opera 12.

Edited by JoWa
Link to comment
Share on other sites

  • 3 weeks later...
On 2013-08-27 at 08:15, JoWa sade:

Enligt SSL Pulse stöder 17 % av de ca 200 000 mest besökta webbsidorna, som är tillgängliga via HTTPS, TLS 1.2 i augusti 2013. I augusti 2012 var det endast 4,5 %. 

I novemberstatistiken ökar TLS 1.2 och 1.1 något mer än föregående månader, 3,8 % respektive 3,4 %.

Av 151 089 undersökta webbsidor stöder nu 48,1 % TLS 1.2 och 45,4 % TLS 1.1.

Den stora förändringen är dock att stödet för SSL 3.0 sjunker från 98,0 % i början av oktober till 60,6 % den 5 november. Den stora minskningen beror förstås på POODLE-attacken som blev känd i mitten av oktober.

Edited by JoWa
Link to comment
Share on other sites

  • 4 weeks later...
  • 3 months later...

Uppdatering angående stöd för SSL 3:

  • I Firefox 34+ är stöd för SSL 3 inaktiverat som standard.
  • I Chrome 39 är nedgradering till SSL 3 blockerad.
  • I Chrome 40+ och Opera 27+ är stöd för SSL 3 inaktiverat som standard.
  • I Opera 12 har stöd för SSL 3 inaktiverats.
  • Safari (OSX, iOS) stöder alltjämt SSL 3, men inte med AES-CBC. Det skyddar mot POODLE, men RC4, det enda tillgängliga chiffret, är sårbart och kan inte göras säkert.
  • Internet Explorer 11, se nedan.

With the 3021952 update of February 11, 2015, SSL 3.0 fallback attempts have been disabled by default in Internet Explorer 11. When will the SSL 3.0 protocol be disabled in Internet Explorer 11?  
Microsoft plans to disable SSL 3.0 by default in Internet Explorer 11 with the April 14, 2015 Internet Explorer update.

https://technet.microsoft.com/en-us/library/security/3009008.aspx

Link to comment
Share on other sites

Det finns ett utkast till IETF-standard som förbjuder användning av SSL 3. Utkastet har det något mordiska namnet draft-ietf-tls-sslv3-diediedie, och rubriken Deprecating Secure Sockets Layer Version 3.0.

Ett annat, relaterat, utkast har nyss av IESG antagits som standard: draft-ietf-tls-downgrade-scsv, TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks. Dokumentet har ännu inte fått sin slutgiltiga utformning av RFC-redaktören, och heller inte RFC-nummer, som alla IETF-standarder har.

SCSV föreslogs av Adam Langley i november 2013, men fick ett genombrott först i samband med POODLE-attacken mot CBC/SSL3, oktober 2014. SCSV erbjuder ett skydd mot nedgraderingsattacker, som tvingar webbläsaren att använda en svagare protokollversion, än den bästa som både server och webbläsare stöder. Chrome 33+ och Firefox 35+ stöder SCSV, och kort efter att POODLE-attakcen hade blivit känd började allt fler servrar att stödja SCSV.

Den senast publicerade TLS-relaterade standarden är RFC 7465, Prohibiting RC4 Cipher Suites. Det handlar om att förbjuda det svaga (sårbara) chiffret RC4. Det egentliga innehållet är mycket kort:

  • TLS clients MUST NOT include RC4 cipher suites in the ClientHello message.
  • TLS servers MUST NOT select an RC4 cipher suite when a TLS client sends such a cipher suite in the ClientHello message.
  • If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate the handshake. The TLS server MAY send the insufficient_security fatal alert in this case.

Klienten (t.ex. webbläsaren) skall alltså dölja sitt eventuella stöd för RC4 genom att inte inkludera RC4 i ClientHello-meddelandet, som innehåller stödda chiffersviter och protokoll. Det är implementerat i IE på Windows 8.1+ och Firefox 36+. Dessa webbläsare använder RC4 endast om servern inte erbjuder något bättre. Om eventuell implementering i Chromium pågår en diskussion i Issue 375342. Det vore förstås bättre att helt ta bort stöd för RC4, men det skulle leda till en ”säker” anslutning till en mängd webbsidor inte kunde göras.

Edited by JoWa
Link to comment
Share on other sites

  • 3 weeks later...
On 2015-03-15 at 22:28, JoWa sade:

Om eventuell implementering i Chromium pågår en diskussion i Issue 375342.

Uppdatering om Chromium:

David Benjamin sade:

Move RC4 behind a fallback.

This is to start gathering better metrics on which servers require RC4. Many servers which prefer RC4 will still accept another cipher suite. Moving it behind a fallback will make our cipher suite metrics reflect roughly servers which require it and not only those which prefer it.

Note that this sort of fallback provides NO security benefit. If a server prefers a non-RC4 cipher, they already securely negotiate it whether or not the client offers RC4. If a server prefers RC4, this kind of fallback does nothing to prevent an attacker from switching the connection to RC4. This is purely for measurement.

https://chromium.googlesource.com/chromium/src/+/a4c9d060fa6e74b6513b198064cfe7b06482d404

I Chrome Canary 43.0.2357.1.

Edited by JoWa
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share