Recent Features
| |||||||||||||
Scary SSL warningsScary SSL warningsPosted Apr 13, 2012 13:22 UTC (Fri) by sorpigal (subscriber, #36106)In reply to: Scary SSL warnings by Jan_Zerebecki Parent article: Langley: False Start's Failure
Just come up with a way to visually distinguished Verified vs Not-Verified in addition to SSL vs No-SSL and call it a day.
If browser vendors were really interested in communicating with users about whether they're safe then non-encrypted http connections would be flagged with a scary, red URL bar with a clickable information button which describes the dangers of browsing unencrypted. Saying that "Users expect https to be safe" is just making excuses; users expect "green" to mean safe, not S.
(Log in to post comments)
Scary SSL warnings Posted Apr 14, 2012 0:06 UTC (Sat) by josh (subscriber, #17465) [Link]
> Just come up with a way to visually distinguished Verified vs Not-Verified in addition to SSL vs No-SSL and call it a day.
If browsers had started out by never showing users the protocol (http versus https) and treating https with an unverifiable certificate as identical security to http, then sure, we could have opportunistic encryption today that would at least protect against passive packet sniffing, and users would know to look for the verification information rather than the protocol string. But with the state of browsers today, allowing https with an unverifiable certificate would let users get exploited.
Scary SSL warnings Posted Apr 14, 2012 12:27 UTC (Sat) by Jan_Zerebecki (guest, #70319) [Link]
The differentiation between http and https is also a technical part of the security. Take the following example:
Request 1 to https://example.com/ is verified to be signed by a trusted CA. This triggers the rainbows and padlocks in the UI, all went fine security wise. The user fills out a form on the page and sends it, now Request 2 is POSTed to the same URL. This time a self signed certificate is used because a MAn in the Middle attack happened. In your proposed change there is nothing available to let the Browser differentiate between a successful attack that uses a self-signed certificate and the correct certificate. That is because in the current scheme of things there is no client state about the identity of a site.
Poking holes in this argument is welcome.
HTTP Strict Transport Security changes this, but it doesn't have a mechanism for the initial distribution of the identity. One could put this HSTS information in DNSSEC (there are proposals for that). (Additionally allowing only the public key or the hash without HSTS in DNSSEC is IMHO important.)
That would solve most of the problems of the current system I know of. It doesn't need any flag day and can be used by those who want without cooperation from anyone else. It makes it easier for the untrained user to be more secure than the current mechanisms.
But there are downsides: It is much more complicated for the administrators of the system. (Although it scales, i.e. one knowledgeable person can ensure it works for basically unlimited systems once the procedures and software is in place. But if you trust your DNS Server operator he could do this for you and what is left is not really more complicated than it is now.) And the software neither on the client nor on the server is yet finished (never mind deployed).
What is left is the standardization, implementation work and convincing your browser vendor to ship such an implementation (not in that order). If that wasn't enough work I fully expect someone to find some legacy related use case that would prevent all of this (just as with IPv6, HTTP Pipelining, TCP ECN, etc...).
Probably that in the absence of saved HSTS records for a host you must decide between being vulnerable to downgrade to the current CA model or being disconnected from any HTTPS site in parts of the internet DNSSEC queries are broken in. That may be because fully (from the root) resolving without an intermediary is somehow filtered outside of your control (i.e. DNS is blocked) and the resolver assigned to you (also outside of your control) does strip or choke on DNSSEC.
Does anyone know if that is a problem in practice and how widespread it might be? Or any other problems with this way of solving it?
Scary SSL warnings Posted Apr 16, 2012 13:53 UTC (Mon) by nye (guest, #51576) [Link]
>The user fills out a form on the page and sends it, now Request 2 is POSTed to the same URL. This time a self signed certificate is used because a MAn in the Middle attack happened. In your proposed change there is nothing available to let the Browser differentiate between a successful attack that uses a self-signed certificate and the correct certificate. That is because in the current scheme of things there is no client state about the identity of a site.
Realistically, there should be.
Even aside from how you want to treat self-signed certificates, a browser should think something's up if the certificate for a given URL changes between two requests, unless the first certificate was right on the edge of its expiration date. Keeping a record of the certificate received on the last request would be an improvement even if you continue to treat self-signed certificates the same way.
Do any browsers currently do that?
|
|||||||||||||