Timeline for How can end-users detect malicious attempts at SSL spoofing when the network already has an authorized SSL proxy?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 17, 2017 at 13:21 | history | edited | CommunityBot |
replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
|
|
| Jun 21, 2012 at 15:39 | comment | added | Bruno |
@curiousguy, I haven't tried to delete known CAs, but that's the way exceptions work (TOFU as you said). If you can verify addons.mozilla.org manually the first time, it should be fine for subsequent visits (with "permanently add exception"). Of course, you'll have to do the initial validation manually the first time (it's possible to view the details and compare with the value from another browser, for example).
|
|
| Jun 21, 2012 at 15:15 | comment | added | curiousguy | @Bruno "in Firefox, remove all trusted CA certs and add exceptions for everything" Which FF version have you tried? Can you still browse addons.mozilla.org ? Does the automatic extension update work? | |
| Jun 21, 2012 at 15:02 | comment | added | curiousguy | (...) On Firefox you can use CertPatrol to detect changes. I believe the restricted Chrome extension interface does not support checking certificates. | |
| Jun 21, 2012 at 14:58 | comment | added | curiousguy | @Benoît "Anyway, is there a way to configure Firefox or Chrome to act like an ssh client ? I mean on first connection, it acts you to validate the key/certificate and on next connection it will warn/block you if your peer ID has changed ?" Good question! What you describe is called "TOFU" for Trust On First Use, it does not have authorities (so cannot have corrupt authorities), and ask user questions such as "The key fingerprint is blablabla" and "WARNING! The key fingerprint has changed" which requires a minimal technical understanding. | |
| Jun 20, 2012 at 21:49 | comment | added | Bruno | As for monitoring change, you can either (a) use a tool like Convergence (although that will always raise warnings with a MITM proxy) or (b) in Firefox, remove all trusted CA certs and add exceptions for everything, you'll get a similar behaviour to what you see with SSH (you'll still get issues if the MITM proxy doesn't cache the certs, but re-generate a new one on the fly every time, even if the site has already been visited). | |
| Jun 20, 2012 at 21:46 | comment | added | Bruno | @Benoît the fact that the browser didn't warn you is part of the PKI flexibility: this is actually very useful to be able to update certificates (which have a date limit). In contrast, plain public keys (as used in SSH) don't have an expiry date, and you rarely have a initial known value to compare them against. "CA injection" would indeed be a perfect attack for a lot of things, but choosing which CAs are trusted isn't done remotely. Again, what you're worried about relies on someone (who had the permission to do so) adding that MITM CA cert to your trusted list: you can't fight against that. | |
| Jun 20, 2012 at 21:17 | comment | added | Benoît | Anyway, is there a way to configure Firefox or Chrome to act like an ssh client ? I mean on first connection, it acts you to validate the key/certificate and on next connection it will warn/block you if your peer ID has changed ? | |
| Jun 20, 2012 at 21:13 | comment | added | Benoît | I'd like to add that i was scared by that fact that Chrome didn't warn me when the certificate changed for some website. For example, i used to work a lot on netapp.com and when they put in place the MITM proxy, a new proxy-signed certificate replaced the genuine one and Chrome did not bother to tell me. Isn't cert authority injection the perfect attack for phishing websites ? | |
| Jun 20, 2012 at 20:10 | comment | added | Iszi | @curiousguy That's an option for the problem of validating certificates. The only caveat to bear in mind there is that we're still left with the issue of securing transmissions from the corporate "Big Brother" - to which, the only answer (again) is: don't do anything you don't want them to see you doing. | |
| Jun 20, 2012 at 20:05 | comment | added | curiousguy | You could setup your own SSL proxy at home, and then connect to it. You will control the validation of site certificates. (You cannot control the validation of your home computer certificate, obviously.) | |
| Jun 20, 2012 at 18:49 | comment | added | Bruno | @IsziRoryorIsnti Although SSL/TLS and HTTP are rather independent in HTTPS, in principle, this could be done quite easily when the proxy generate its certificate on the fly by placing the original certificate in a non-critical extension with its own OID, for example. The problem is that there would need to be a way in the browser to check that extension. This could be a bit tricky since the UI would need to take into account two chains of certificates. | |
| Jun 20, 2012 at 18:43 | comment | added | Iszi | I suppose the only way around trusting the proxy for validation, would be for the proxy to somehow provide the original cert alongside its spoofed cert. But then, that could allow an industrious individual a means to bypass the proxy I suppose. | |
| Jun 20, 2012 at 18:38 | comment | added | Bruno | @IsziRoryorIsnti It's not ideal indeed, but if there's a MITM proxy, your SSL/TLS connection will end up there. You won't be able to see/change what it does beyond, when connecting to the target server. It won't have access to the target server's private key either, so the target server has no way to delegate its identity (and it shouldn't, really). What these proxies are doing is effectively a MITM attack with the consent of the client's admin. You just have to hope that the pseudo-attacker acts in the overall interest of the company ("with great power comes great responsibility..."). | |
| Jun 20, 2012 at 18:26 | comment | added | Iszi | Good answer, but I disagree with trusting the proxy to do the certificate validation for you. While I'm not familiar with the operation of SSL proxies myself, I expect this is something that can easily be broken by a bad configuration. If you need to trust an HTTPS cert (and let's presume this is for business purposes authorized by the company running the proxy) it would be best to have a way to validate it yourself - proxy or not. | |
| Jun 20, 2012 at 18:21 | history | answered | Bruno | CC BY-SA 3.0 |