Opportunistic Encryption for Firefox
bitsup.blogspot.com
bitsup.blogspot.com
I really dislike that browsers seem to treat self-signed certificates as worse than plain HTTP (in that self-signed certificates cause a big scary yellow warning that looks similar to the big scary red warning for invalid certs).
Self-signed certs are bad insofar as you can't prove that someone else isn't MITMing the connection and serving you an encrypted, but untrustworthy, proxy page. But with plain HTTP, you already have no guarantees that that isn't happening![0]
If I understand it correctly, this seems to combine the best of both: encouraging the use of self-signed certificates over plain HTTP, while still rewarding verified certs (ie, signed by a trusted third party) over self-signed.
[0] If you really care, you should use a CA-signed cert. But every attack that possible when using self-signed certs is not only possible when using plain HTTP, but much easier to execute, and also much easier to execute silently.
Some argue that all communication should be encrypted, but that's another issue.
>Connection is encrypted but authenticity cannot be confirmed. Connection is not secure unless you thrust the fingerprint!
2. Certificate errors are much more confusing than a failure to connect.
The S stands for "this connection is on port 443 and has been negotiated with TLS". That means it's being encrypted and has been authenticated.
> HTTP 1 and 2 are miles apart and get the same protocol marker.
Which was and is a terrible terrible idea and among the many reasons I dislike HTTP2.
> So a secure connection with TLS gets shown as HTTPS, and an insecure connection with TLS gets shown as HTTP.
Which is a terrible terrible idea. The protocol marker should denote the protocol used, not some fluffy stuff that doesn't really mean anything to the user.
That's just a default.
>That means it's being encrypted and has been authenticated.
Except that TLS does not always imply encrypted and authentication. You can use TLS with a self-signed cert. You can use TLS with a broken cipher. You can use SSL_NULL_WITH_NULL_NULL. Browsers will helpfully provide things like a slash through the https in cases like this.
Whether the connection is actually encrypted and authenticated is what the vast majority of users care about. I'm not sure how you can call that fluff.
(Now as far as http 2, it's tricky because it's kind of at a lower layer that still runs http on top. And when you're linking to something you don't care about whether that layer exists. So there are pluses and minuses to having http2:// or spdy:// or whatnot. Not that any of that matters, because cocksure middleboxes nearly force it to continue to use http://.)
And your point is? If there is no port specified, that's what it's on if the protocol is HTTPS?
> You can use TLS with a broken cipher. You can use SSL_NULL_WITH_NULL_NULL. Browsers will helpfully provide things like a slash through the https in cases like this.
As they should, because allowing such things to happen automatically is contrary to what the spec is expecting to happen:
> If the hostname does not match the identity in the certificate, user > oriented clients MUST either notify the user (clients MAY give the > user the opportunity to continue with the connection in any case) or > terminate the connection with a bad certificate error.
elsewhere
> In order to prevent this form of attack, users should carefully > examine the certificate presented by the server to determine if it > meets their expectations.
- RFC 2818 "HTTP over TLS" (http://tools.ietf.org/html/rfc2818)
(for the second quote, the User Agent automates that process to make sure the certificate meets trust and expiration and the cipher suite meets exceptions.)
Why not adopt the SSH model of accepting the server's cert at the first connection and then complaining loudly if the fingerprint changes? Or even go a step further and have browsers manage private keys (client certs) which identify the user? Some Linuxes already do this with SSH: if you have a private SSH key, an SSH agent will remember its decrypted form on first use, and use it for SSH auth.
The client certs can be exchanged in a standard format throughout browsers and devices, and mobile phone-based two-factor-authentication can be used to increase security.
So - bam, good enough MITM protection (sure, let the banks retain the PKI system), no passwords, and a completely ready implementation requiring no new standards. There is no requirement for the client certs to be "blessed" with strong identification with the person, so anonymity is achievable by having an arbitrary number of different client certs.
However, the bigger thing a self-signed cert allows you is the ability to verify later if your communication has been snooped by an active attacker--which is very significant. It's problematic that the communications aren't authenticated before they occur, but that doesn't mean they can't be authenticated later (via CAs or other means).
A slightly more sophisticated attack, indeed — but one that doesn't scale well. It ups the cost of mass surveillance tremendously.
As far as I can tell, both insertion of a passive listener and a MITM are algorithmically O(n) on the number of connections being surveilled. All you're increasing for the MITM is the constant factor.
When you're on the order of billions of connections being surveilled, even linear growth is hard, but we know that the NSA already has done that. Increasing the difficulty by a constant factor is not much harder, and there's no question that the NSA has the budget to do so. And in fact, the constant factor isn't even large: it's whatever the resource costs of two connection handshakes per connection is, plus decryption/encryption on the data flowing across, all of which are highly optimized algorithms at this point.
That's point 1.
Point 2: Detection.
Actively MITM-ing an SSL connection requires you to (if the CA Chain-O'-Trust works as supposed) give away the fact that you own a (valuable!) compromised CA authoritative cert. You would want to use such a cert for a targeted attack, not waste it on blanket surveillance and get found out (and called out) within a couple of days.
If you don't own a root cert but rely on vulnerable implementations, or implementations such as this one which do not rely on the CA infra, same story. You do not want to waste that on blanket surveillance and get caught. You'd save it for the /special occasions/.
SSL-MITMing everyone, all the time, as in blanket surveillance, is unfeasable even without CA chains. You'll get called out on it by people that do check cert fingerprints once in a while.
This is a different kind of scalability than the computational order-of-complexity one that you seem to be thinking about.
Typical mildly advanced user thinks this way:
I see https:// in URL bar and no scary red/yellow untrusted cert dialog? -- Ok I am all set to type my credit card number in.
There are the green brackground in there too, which I forget what it means, but it presumes some extra "security/authentication" thing.
What should the encrypted but not authenticated mode show? https:// with a yellow or gray bar? Try to teach the user about is the difference between authenticated vs encrypted. Warn them once and put a "Got it, do not bother me again" dialog.
Remember windows vista with "deny or allow?" dialog every single time you did anything with your computer. The intent was good but how the users perceived it was the problem. Here it is the same problem.
That's what's attractive to me about Firefox's opportunistic encryption proposal. It really makes no change in the UX compared to an unencrypted connection, not in the URL and not in the time to connect.
My mom for example won't notice. She doesn't know what a URL bar is. She doesn't even look at that place. She clicks on her toolbar for Gmail and other sites she uses. She wouldn't care if it said http:// https:// or foobar://. She will be scared and be afraid to proceed if she would see the "Warning, untrusted certificate!" dialog.
My wife knows something about http vs https. If it says https she knows it is safe to type in her credit card number. https means "secure". But she doesn't know about authentication vs encryption. And will be equally scared about "Warning, untrusted certificate!" dialog. That might as well say "Your computer is hacked and you have a virus".
Anyway just giving a perceptive on how this affects different classes of users. As I put it in another post, it is in large about the UI.
>[0] If you really care, you should use a CA-signed cert. But every attack that possible when using self-signed certs is not only possible when using plain HTTP, but much easier to execute, and also much easier to execute silently.
Right, but the owner of the server you're connecting to is the one that has to choose if the data they're serving or receiving qualifies for protection of this sort. By omission they've basically taken the position that their pages or data are not worth preventing an attacker from MitM'ing you. If you allow self-signed certificates to fly without a warning at that point you're taking the decision to secure from a MitM attack away from the server owner that wants to protect their pages. Sure, a savvy user would notice a change, but what if they've never been to that site before?
Here's a scenario: Bob's Widgets sells Widget 9000 and has a secure site with a certificate signed by a CA. Alice hops on free WiFi at a Widget convention and visits for the first time, hoping to buy some of these amazing widgets Bob sells. Except Mallory intercepted the traffic and swapped out a self signed certificate. Bob's only way of telling Alice that his certificate and therefore traffic is authentic is by using one signed by a trusted third party.
Now that isn't to say that I don't think your idea has merit. It just doesn't fit into how we currently do things. What might work is a keeping port 80 and port 443. Port 80 is secured by a self-signed certificate but the user isn't informed (via their browser's indicators, like a green icon or what-have-you) that their connection is secure because it isn't in the sense that it will protect them from MitM attacks. It is however encrypted and you can have the browsers trigger warnings when the key changes similar to the way SSH does. 443 still behaves exactly the same where users only trust CA signed certs by default.
Once again, if you advocate using HTTP, go ahead and drop ssh in favor of telnet.
Assuming you mean drop HTTP over bare TCP, and are advocating for HTTP over TLS, then everyone knows that is the right thing to aim for. But advocating revolution won't get anywhere since there is a phenomenal number of systems to update. Just like IPv6 deployment, it will take decades before HTTP over bare TCP is removed. The article is an excellent proposal because it helps migration.
Certificates do need to be sorted out. Heck they currently hinge on names, yet what name does a random router bought at Best Buy and plugged into my network have? Or the armada of IOT devices coming along - thermostats, fridges, light bulbs?
I am advocation for a revolution. We have the technology today, and after Let's Encrypt goes live all we really need is for Google to announce that Chrome will run for six months with a warning when using HTTP (similar to what it does bow for self-signed certs) and the will stop supporting HTTP altogether. How quickly do you figure people will move if this was announced?
Or in other words, you could cut off support for the major sites/devices using HTTP, but could never do it for everything in the next 6 months.
Since you are advocating TLS support being mandatory, then it dropping HTTP for a different protocol is worth considering. HTTP/2 is a strong consideration, and currently is always over TLS.
Ok, now try and word one of those so that regular folk understand what the heck it is saying. And your "legacy mode" means HTTP is still supported.
There is nothing wrong with deprecating HTTP over bare TCP, but being completely unsupported in the near future is unworkable. Everyone including this effort is about a slow steady migration.
I think a better approach might be to separate encryption from trust.
I'm thinking back to Chrome's announcement that they were considering making http:// show some sort of warning.
What if:
* We make HTTP show up as "insecure" in browsers
* We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http
* We make HTTPS with Trust show up the way we currently show HTTPS
* Keep EV Certs the same
> * We make HTTPS work with self-signed certificates, and display websites encrypted that way the same way we currently show http
Clear text and opportunistic encryption should have exactly the same UI. Security UIs are already too confusing, and we shouldn't introduce more complexity. Besides, one should never make a decision based on a clear text vs OE distinction, since OE is so easily defeated.
Now if just Firefox would store and check fingerprints of self-signed certificates, we would get the exact same benefit when telnet was replaced by ssh.
In a sense telnet/ssh is exactly like http/http_with_oe. And still we make a big deal out of the telnet/ssh difference while saying that http with OE is only marginally better than http.
Of course it's not nearly that black and white because ssh stores the fingerprint, meaning you are safe if (and only if) your first connection wasn't intercepted.
For example, in the case of self-signed certificates, the browser knows it is encrypting a message to the holder of the self-signed certificate, but there's no information on who that is. The certificate sent could be changed, and there's no way to know something is wrong.
Put another way, plain text is readable by anyone. Text properly encrypted to a known recipient is readable only by that recipient. But text encrypted to an unknown recipient is readable by only one entity, but that entity could be anyone, so it's equivalent to plain text.
I strongly recommend using full authentication whenever possible, of course, but in the cases where that is not (yet?) practical, enabling auto-generated self-signed certificates for TLS should usually be a very simple change.
Really, the only people that I expect would be against such an easy change are people doing NSA-style spying or businesses with a surveillance-based business model.
If there was a big shift to encryption without verification, passive attacks could just start shifting to active ones. In most cases they're in place to do so. I suppose the major exception is optical splitter scenarios. But what's stopping them from replacing the splitter with another hop?
Shift from WHAT? Remember, nobody is suggesting shifting anything from proper encryption, or changing the UI in any way that might mislead a user into thinking they were using a "secure" connection. This is a replacement for plaintext only.
> But what's stopping them from replacing the splitter with another hop?
Cost and complexity. Which is to say, if anybody really wants to throw a few megabucks at the problem, they will succeed, but that is not a contingency that some threat models worry about.
I will refer to Dan Geer when he said[1] (and I suggest this is true for the corporation as well as government):
The central dynamic internal to government is, and always
has been, that the only way ... to control the many sub-units
of government is by way of how much money [it] can hand out.
...
Suppose, however, that surveillance becomes too cheap to meter,
that is to say too cheap to limit through budgetary processes.
Make the eavesdropper work for it, instead of simply folding because they might decide to upgrade to a MitM.
An even better question, though, is why are you so interested in keeping the internet in plaintext?
[1] http://geer.tinho.net/geer.blackhat.6viii14.txt
[2] for whatever definition of "everybody" you prefer
Then how do you know you are getting any sort of encryption?
OE provides unauthenticated encryption over TLS for data that would otherwise be
carried via clear text. This creates some confidentiality in the face of passive
eavesdropping,
and also provides you much better integrity protection for your data than raw
TCP does when dealing with random network noise
To use OE, you have to set up an SSL service in the first place, so just take the extra 15 minutes and make a real signed certificate. There is no such thing as "kind of" secure, after all. Encryption is intended to provide security. OE is not secure.
>There is no such thing as "kind of" secure, after all.
If you really want to get absolute, then you have to admit that any computer you have purchased parts for is not secure.
Levels of security exist.
It's an arms race. If I have sensitive data, you install a tap to capture it. If I begin obscuring the data from you rtap, you begin injecting traffic to unobscure it.
If someone is trying to steal your data, they will not stop trying to steal it just because you applied ROT13 to it. Why do you think someone would just give up just because they now need to use an active attack? Active attacks are trivial once a tap is in place. We're not talking NSA research projects here; this shit has been going on since World War II. If they have a means to exploit your data, they will use it.
Even if I leave the door unlocked and the keys under the seat.
Lets look at a real-world example here. Say an adversary is tapping one of the Atlantic cables between US and EU. That is what, a few T/s of data, and a few millions of concurrent connections. Then try to do a practical MIT attack (a write) for each of those connections, while maintaining data speed. Also, you must be 100% undetectable.
Can you do that?
- Google driving by with it's street view cars and capturing all your wifi traffic for later analysis is passive.
- People sitting in a coffee shop and capturing your wifi traffic is passive.
OE protects against these attack vectors. It does not protect against other attack vectors, but that does not mean it's harmful or useless.
Moreover, with pins it could be a first step to get rid of CAs.
OE does NOT protect against this. If you can read wifi packets you can write them and MITM. You're basically arguing that at the moment it's more likely that they are using a snooping package that doesn't MITM. Sorta like "use Mac/Linux cause there's no viruses/malware/keyloggers". If there's a shift to OE, then sniffing packages will provide plugins to MITM OE when possible.
So sure, turn on OE, it won't _hurt_ if we don't tell the users via UI that there's anything special going on. It's like a CRC check to prevent minor accidents.
With google street view you're barely even in range long enough to pick up a couple packets, if the person was even using their computer while the car drove by; this is not what OE is designed to protect against. If the car sat outside their house, they'd still get owned, and OE would still not be useful.
Sitting on a cafe's wireless is literally the de-facto example of how to actively sniff or inject traffic on an unsuspecting victim. The only more bluntly useless case for OE is a state-sponsored mitm using coercion-induced signed certificates.
And you can't get rid of CAs.
This is real problem for http cleartext data which data transported over TLS does not have.
Alice sends Bob a link: http://example.com
Bob trusts Alice and now knows that example.com is probably ment to be accessed over HTTP. Now for the next example:
Alice sends Bob a link: https://example.com
With the current implementation of browsers Bob knows that example.com should present a CA signed certificate. But what if example.com wants to encrypt their data, but for whatever reason uses a self-signed certificate? Some people say that Bob's browser should not display a "big scary" warning, but instead display a UI similar to when accessing a HTTP site. However, in this situation HTTPS has lost some meaning. I think http2 should work as follows:
http2:// - encrypted, not verified
https2:// - encrypted and verified
This way the protocol still conveys the same level of information.
However, if it were completely up to me, I would say ditch the CAs and use namecoin to verify certificates.
That's why self-signed certificates work in this context; the identity of the server's not supposed to be validated (unencrypted HTTP can't validate server identities), so the browser can accept a self-signed certificate without warning.
There's no change to how certificates are authenticated when accessing a site via an https:// URL.
Please, please, please, please no. Any kind of blockchain is far too vulnerable to attacks here to be a good source of authority.
The only real trust that would work is distributed trust. The CA system is kind of a joke.
That said, yes, it does protect coffee shop HTTPS browsing better than a self-signed cert.
This, together with TACK or Certificate Transparency could be a CA killer.
For bonus points such a standard should incorporate a web of trust system that can not be overridden by a bogus certificate in the regular system. Ideally a self signed certificate provided by someone you can physically visit should be more secure than what we have now.
Added: I guess my point is that we are thinking about this backwards. A verified self signed certificate is the gold standard, not some inferior alternative. I should be able to walk into my bank and then walk out with a certificate on a USB key that can not be messed with. If we are going to change things we should strive to end up with the possibility of something better than what we have now.
① https://www.iana.org/assignments/tls-extensiontype-values/tl...
If it's self signed, and going to throw massive warnings with a direct connection, shouldn't you use anything other than 443?
Any subtleties I should be aware of?
If you don't have a CA certificate, you're probably not advertising your https:// URLs anyway, so unless search engines are aggressively looking/prioritizing for https transport, it wouldn't seem to hurt anything to run a self-signed certificate there.
There's a lot more to change if I want real HTTPS support. Changing a single port number is the least of my worries.
However, for HTTP it's the best thing possible at this point.