Ziet de gemiddelde gebruiker wanneer producten als van blue coat er met een mitm tussen zit?
Kijken naar een slotje alleen helpt niet.

Wordt het onderhand niet tijd voor een software oplossingen/browser extensies die gebruikers gaan waarschuwen wanneer een verbinding is onderbroken door een luistervink op de lijn?
Zijn die er al?
Welke dan?

En hoe komen al die 3 letter diensten dan aan hun big data?

Ga naar een site met een EV certificaat, zoals de meeste banken. Bluecoat en (de meeste?) andere MitM devices kunnen geen EV uitgeven voor dergelijke domeinen. Je ziet dan geen EV identificatie en je weet dus dat er iemand in je bankverkeer mee heeft zitten kijken.

Peter

Ja die is er als Tracker SSL, die het percentage aan onveilige tracking aangeeft, m.n. waarvan NSA gebruik en misbruik van maakt. Verder ben je dus overgeleverd aan het veiligheidsbesef van website eigenaar, hoster en wie er verder nog voor de verbinding en het transport van de data zorg draagt. Outsourcing is vertrouwen geven tot ??? e2e...niet overal.

Je ziet het met die afluisterberen. Overal kan een datalek ontstaan door onkunde en lompe incompetentie.
Zijn uw sri-hashes gegenereerd. Input output validatie via nonces, security headers geimplementeeerd, praat uw server software niet te luid - excessieve info proliferatie? Zijn de certificaatjes als root geimplementeerd of gekaapt door een man in the middle dienst? Fingerprinting lekken. Inline scripting, zondigen tegen 'same policy'.

Het is een wonder dat het nog zo vaak goed gaat.

Te weinig die er weet van hebben en dus is eenoog koning in het land der blinden en kan de data graaier vaak ongezien zijn gang gaan.

luntrus

Opvallend, ook dit is een geval waarin Google zegt: "we gaan dit doen, dan weet je dat, zorg maar dat je het oplost" tegen een leverancier. Daarna is de ander schuld als er dingen kapot gaan. Dit soort arrogantie is toch belachelijk? Wanneer ik bij een ander iets graag aangepast heb, dan bespreek ik dit, overleg, wat een redelijke termijn is om dit te bereiken en check ik het voor ik verder ga.

Aangezien Google niet kan overzien, wat het voor Bluecoat inhoud, zou dat normaal moeten zijn. Natuurlijk, wanneer het over veiligheid gaat, moet er wel een eindige termijn zijn in de zin van maanden i.p.v. jaren, maar dat is iets anders dan deze manier.

Google doet iets volgens de specificaties! Dan kun je ze niet verwijten dat partijen (Bluecoat met name) die proberen de specificaties te breken daar vervolgens problemen mee krijgen. Dat is de zaak omdraaien.


Je begrijpt niet helemaal wat Bluecoat doet volgens mij... Intercepting TLS traffic is nu precies wat je eigenlijk niet wilt en wat verboden zou moeten zijn.

[paranoid mode]
Voor de anderen: zoek eens uit van wie Bluecoat is, en kijk dan wie certificaten uit geeft. Trek vervolgens je conclusies over 3 letter organisaties. Bluecoat heeft in het verleden geleverd aan zeer verdachte regimes zoals Syrie.
[/paranoid mode]

Let op het woordje DRAFT bovenaan:
https://tools.ietf.org/html/draft-ietf-tls-tls13-18

TLS 1.3 is een standaard die ontwikkeld wordt door de IETF, niet alleen door Google. Deze standaard zit er al ruim een half jaar aan te komen, wat voldoet aan jou termijn van maanden. Daarnaast heeft Mozilla in Firefox ook sinds deze maand TLS 1.3 aangezet dus dat het arrogantie van Google betreft slaat de plank volledig mis.

Het lijkt me juist dat het allemaal werkt zoals bedoeld: als er malware een man in the middle aanval uitvoert ontstaan er problemen.

waarom rolt de school niet terug en waarom hebben ze mega-dure shit welke nog steeds geen 1.3 ondersteunt?

ja en waarom doen Google en firefox het weer anders dan ons buitenbeentje Microsoft?

De veiligheid, ook van TLS 1.3, is afhankelijk van het beveiligingsniveau, te weten de waarde van de te beveiligen data.
Je moet goed weten wat een bepaalde protocol versie doet en niet doet, omdat er daar nog wat misverstanden over bestaan.

Sta je null encryptie toe op je webserver, heb je al een levensgroot probleem. Je hebt wel SSL maar zonder encryptie.. De zwakste schakel is altijd de zwakste trusted root en wat voor DNS er dan gebruikt gaat worden. Check het certificaat, hoe zit het met de veiligheid. Wie gaf de trust chain uit?

Kan men via een https MiM proxy de CA certificaten die je hebt aanpassen, dan ben je in feite het beheer over je netwerk kwijt, dan is het controleren van je DNS resolutie ook al niet meer relevant.Ze kunnen zo IP adressen forceren e.d.

Lees alles in een grotere context en diepgang hier eens door op StackOverflow door Peter Smit en zijn kompanen daar bediscussieerd: https://security.stackexchange.com/questions/5/does-an-established-ssl-connection-mean-a-line-is-really-secure

De discussie is al wat gedateerd, maar de fundamentele principes rond de protocolbeveiligingsaspecten blijven wel hetzelfde. Alles staat of valt met trust en validatie. Hoop dat dit bijdraagt aan de discussie hier.

luntrus

Dat zou opgaan als TLS een protocol was dat Google en Bluecoat voor hun onderlinge communicatie hadden ontworpen. TLS is echter een open standaard die door vele partijen geïmplementeerd wordt (een korte zoekactie leverde een lijst met maar liefst 15 "most notable" TLS-libraries op).

Onderdeel van TLS is dat client en server onderhandelen over de versie die ze ondersteunen, en dat is backwards compatible. Communicatie via Bluecoat-devices zou daarom op TLS 1.2 uit moeten komen en gewoon moeten werken. Dat dit niet gebeurt lijkt op een bug bij Bluecoat te duiden.

Het is lang niet altijd terecht om de wijziging die een probleem triggert als oorzaak van het probleem te zien. Als het beeld klopt dat Bluecoat een bug in de implementatie van een standaard heeft, en een wijziging bij Google die de standaard correct implementeert triggert die bug, dan is het Bluecoat die wat op te lossen heeft, want daar zit dan de fout. Omdat zij een bug hebben moet niet de rest van de wereld op hun gaan wachten. Bluecoat verkoopt namelijk iets aan klanten, en heeft daarmee de verantwoordelijkheid op zich genomen om die klanten ook iets werkends te leveren.

Kennelijk heeft Google Bluecoat maanden van te voren op de hoogte gesteld van de wijziging zodat ze erop voorbereid konden zijn. In een testlab van Bluecoat een nieuwe browserversie testen is beduidend makkelijker te realiseren dan voor een testlab van een browser Bluecoats aan te schaffen. Let wel dat je dan verschillende modellen en firmwareversies nodig hebt, en dat ook voor allerlei andere fabrikanten dan ook moet doen. Dat is niet realistisch. Het lijkt er meer op dat Bluecoat niet of niet in tijd in actie is gekomen.

Maanden zijn mogelijk te weinig om een correcte implementatie van TLS 1.3 op te hoesten, maar dat hoeft ook niet, het protocol waarmee over de te gebruiken versie onderhandeld wordt is niet nieuw en er wordt beweerd dat ze met TLS 1.2 exact hetzelfde probleem hadden. TLS 1.2 is van 2008. Als die bewering klopt lijkt het erop dat Bluecoat deze bug al negen jaar geleden had kunnen oplossen maar dat heeft nagelaten.