The certificate authorities are quite in love that the self-signed certificate errors are turning redder, bolder, and bigger. A self signed certificate warning means "Warning! The admin on the site you're connecting to wants this conversation to be private but it hasn't been proven that he has 200 bucks for us to say he's cool".
But so what if he's cool? Yeah I like my banking website to be "cool" but for 200 bucks I can be just as "cool". A few years back the browsers started putting extra bling on the URL bar if the coolness factor was high enough - if a bank pays 10,000 bucks for a really cool verification, they get a giant green pulsating URL badge. And they should, that means someone had to fax over vials of blood with the governor's seal that it's a legitimate institute in that state or province. But my little 200 dollar, not pulsating but still green certificate means "yeah digitalsushi definitely had 200 bucks and a fax machine, or at least was email@example.com for damned sure".
And that is good enough for users. No errors? It's legit.
What's the difference between me coughing up 200 bucks to make that URL bar green, and then bright red with klaxons cause I didn't cough up the 200 bucks to be sure I am the owner of a personal domain? Like I said, a racket. The certificate authorities love causing a panic. But don't tell me users are any safer just 'cause I had 200 bucks. They're not.
The cert is just for warm and fuzzies. The encryption is to keep snoops out. If I made a browser, I would have 200 dollar "hostmaster" verification be some orange, cautious URL bar - "this person has a site that we have verified to the laziest extent possible without getting sued for not even doing anything at all". But then I probably wouldn't be getting any tips in my jar from the CAs at the end of the day.
no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on".
Treating this as a grave error IMHO is right because by accepting the connection over SSL, you state that the conversation between the user agent and the server is meant to be private.
Unfortunately, there is no way to guarantee that to be true if the identity of the server certificate can't somehow be tied to the identity of the server.
So when you accept the connection unencrypted, you tell the user agent "hey - everything is ok here - I don't care about this conversation to be private", so no error message is shown.
But the moment you accept the connection over ssl, the user agent assumes the connection to be intended to be private and failure to assert identity becomes a terminal issue.
This doesn't mean that the CA way of doing things is the right way - far from it. It's just the best that we currently have.
The solution is absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn't quite come up with.
SSH has. It tells me:
WARNING, You are connecting to this site (fi:ng:er:pr:in:t) for the first time. Do your homework now. IF you deem it trustworthy right now then I will never bother you again UNLESS someone tries to impersonate it in the future.
That model isn't perfect either but it is much preferable over the model that we currently have, which is: Blindly trust everyone who manages to exert control over any one of the 200+ "Certificate Authorities" that someone chose to bake into my browser.
@@@ WARNING! THIS ADDRESS MAY BE DOING SOMETHING NASTY!! @@@
But seriously thanks, I was going into the known_hosts file and manually deleting the offending line :)
IMHO no. We don't SSH to the same 46 servers everyday. But we do log into that many (or more) websites. Can you imagine the amount of homework users need to do in order for this to work?
Not to mention the amount of non-tech savvy users who just won't put up with it.
The way certificate authorities work though, you might visit your bank's "secure" website everyday, with its green padlock and company name displayed, but if one day a rogue authority or a compromised one issues a certificate to someone else, and your DNS resolves to a new server, your browser would not even tell you anything has changed and would happily display the green padlock like it always has.
In the current state of things, you have to do the homework yourself for every site you visit when using HTTPS, while you don't with SSH.
The problem is that this is a huge hassle for incidental visitors. Whereas SSH does not have incidental visitors. Same goes for email, if it's your own server, you know the cert to be the real one, and you can accept it, you're not bothered again.
Encrypted (Certified) COOL GREEN
Encrypted (Self-Signed) EVIL RED
Unencrypted NOTHING / NEUTRAL CHROME
I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain.
> Encrypted (Self-Signed) EVIL RED
Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I know for a fact someone is messing with me.
> Unencrypted NOTHING / NEUTRAL CHROME
This case should be eliminated. We need to stop publishing stuff over HTTP. Period. The browsers should start fast tracking dropping support for HTTP altogether so we don't even have to think about this case.
Now the solution for case #2 is that every time you buy a domain, your registrar should issue you a wildcard cert for that domain. Moreover, you should be able to use that private key + cert to sign additional certs for individual subdomains. That way we can eliminate all the CA's. We would essentially use the same infrastructure that already supports domain name registration and DNS instead of funding a completely parallel, yet deeply flawed CA industry. As a bonus, this way only your registrar and you may issue certs for your domain.
This is all castles in the sky, but IMO that's the correct solution.
> I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain.
Maybe. I just checked my browser and it already trusts more than 100 certificate authorities from all around the world, including some companies that I don't trust, some governments that I don't trust, but mainly composed of organisations I've never heard of. Even in a good system, there would occasionally be leaks etc, but this mess of promiscuous trust is clearly insane.
Even if the browser only had a single authority you do trust... how easy would it be for someone to force them to do something to compromise your trust? For instance with an NSL bound with a gag order?
By having several authorities you do trust? Preferably in different jurisdictions and parts of the world. But only those who you do trust.
A system where there's a .com root cert that can sign authority certs for .com subdomains, which themselves can only sign for their own subdomains - that's a great idea. Not part of the standard, though.
But with a delegated chain of certs, the problem does get worse - not least because you'd require individual domains to manage their own certificate revocation.
But since there's basically no secure way to obtain CRLs or perform OCSP cert validation, it's kind of moot.
As currently implemented this is mostly correct. I don't think the CAs want that situation to change, but it really harms the usability of the entire system.
This is a short sighted solution. If you go this route, then you are constraining authentication to the client. Users always choose bad passwords, so we are stuck.
In mobile networks, you have the network in a position to strongly authenticate the subscriber, without necessitating the weaknesses that can come with bad passwords.
I generally agree that TLS is desirable, but if we go all in, there are interesting and potentially more desirable alternatives that are lost.
Also, while mobile networks can authenticate my mobile phone and the hops from my phone to their edge router can be "trusted" (don't forget that the NSA is snooping here), I want end to end encryption. I want to know that the only two entities able to send/receive data are the site I'm trying to talk to and myself.
Let's think about it this way: in 2014 I propose a new protocol and implementation where you run a program on your device and I push arbitrary code to it. I also include code from advertisers, partners, third party affiliates, and my buddy Dave. All of this is done over clear text with no authentication, no authorization, no proof of identity or ownership, and over unsecured networks. Here's the link to the installer :) Yeah, I wouldn't sign up for that either.
In my opinion the rationality of your perspective is one of the most damaging consequences of the NSA's behavior.
Attacking the client is easy for both hackers and nation states. Moving the control to infrastructure tends to cut out whole swaths of script kiddies. There are important scenarios where this makes a ton of sense (m2m, iot, many mobile apps) and those assholes have just burned everyone's trust to the point that nascent solutions are no longer viable.
There is an opportunity for new authentication approaches that can't exist in a TLS-everywhere world.
I'm looking at http://en.wikipedia.org/wiki/Generic_Bootstrapping_Architect... in particular.
HTTP is perfectly fine for information originating on and never leaving controlled, trusted, internal networks, and there is no reason to pay the overhead for HTTPS for those cases.
There's other use cases where its probably not worth the (small) overhead for HTTPS.
- Your small blog you publish over HTTP is now opening the door for me, the attacker to mess with any traffic originating from your site. Say you host your resume on your site. I can substitute it with a much less flattering version. Say you host a code snippet. I can add a little obfuscated fork bomb or root kit at the end. Say you have a referral link to Amazon. I send your users to amazom.com, a site that's MitM'ing amazon.com but captures credit card details on the payment form.
- Your internal corporate system is great an all, until you have an unrelated breach and the HTTP site becomes a vector for me to attack your systems. Or worse yet, I learn how to trick your users into believing they are accessing your genuine document store when in fact they are uploading their secret company plans to my very own rogue site. Trust inside the electrified fence is different than on the Internet, but a self-signed cert that your IT sends to every employee is also pretty easy. Conversely, if your organization is so large that it's impractical, just buy a $10 domain and a $8 TLS cert. The "overhead" you speak of does not exist when your server side stops supporting HTTP. FFS, configuring nginx to use TLS/HTTPS takes exactly 3 additional lines of configuration code as compared to an HTTP-only site.
Only if you control any of the infrastructure. If you do, then you can make my life a misery anyway, encrypted or not.
If you use HTTPS everywhere, there is a tiny bit (but usually negligible) runtime overhead, a bit of process overhead (which this announcement is pushing much closer to zero), and significant simplicity in many other axes. I think the tradeoff leans towards publishing internal sites with globally-valid HTTPS certificates.
I'm hoping the EFF project will smooth over these hiccups, which is why I'm looking forward to it.
Then everyone stops using that registrar and they go out of business.
> Or what about revoking the previous cert?
You're asking this as if there is some kind of functioning method of revoking certificates already. If anything this makes it easier because it could be plausible for clients to somehow retrieve who the registrar is for the domain and then only accept certificates signed by that registrar.
The fact that they still stay means (and this is relevant to the EFF project as well), creating alternatives is just as hard as making enough people know and care about them.
The registrar check per domain is probably the biggest plus in having it act as CA. Of course, that adds overhead to the registrar which they may not be willing to accept (margins and all that).
As long as you can transfer the domain out I guess it's not too bad.
- they sell you the domain name. Doesn't matter how you try to authenticate yourself to clients (cert pinning aside), the registrar can seize the domain at any point.
- they control what your authoritative name servers are. They could easily change these on you.
- they populate the whois database, which is used when you purchase your TLS certs. This means that a registrar can list firstname.lastname@example.org as you the contact, and have Joe get a completely valid cert.
- one important issue that the article does not mention is that you are forever locked into trusting the site operator. This means that you as a user already must trust another entity.
This, what I am proposing is that out of the current trust list: [site owner, registrar. CA] we cut out the CA. Once again, the registrar always trumps the CA in their ability to seize your domain. At the same time, the CA provides zero protection against the registrar misbehaving. This article talks about shifting trust from the CA to the registrar and how that's bad. I posit that you already trust the registrar, forever (or as long as you are willing to use their TLD) so you would be strictly reducing the amount of entities you need to trust, never adding new ones.
There are plenty of other things to complain about. EV for one.
Encrypted (Certified) EVERYTHING'S FINE
Encrypted (Self-Signed) OMG!!!
Unencrypted EVERYTHING'S FINE (while it's not)
Encrypted (Certified) AUTHENTICATED & ENCRYPTED
Encrypted (Self-Signed) NOT AUTHENTICATED & ENCRYPTED
Unencrypted NOT AUTHENTICATED & NOT ENCRYPTED
Connecting to a blog? Encryption is a plus (and is the topic of this very HN post). But unencrypted is also okay.
The original CA system was not designed to defend against mass surveillance so it had little incentive to separate these concerns.
No, I wouldn't say so. Having SSL is better than having nothing pretty much on any site. But if you don't want to pay $200 somebody for nothing, you would probably consider using http by default on your site, because it just looks "safer" to the user that knows nothing about cryptography because of how browsers behave. Which is nonsense. It's worse than nothing.
And CA are not "authorities" at all. They could lie to you, they could be compromised. Of course, the fact that this certificate has been confirmed by "somebody" makes it a little more reliable than if it never was confirmed by anyone at all, but these "somebodies", CA, don't have any control over the situation, it's just some guys that came up with idea to make money like that early enough. You are as good CA as Symantec is, you can just start selling certificates and it would be the same — except, well, you are just some guy, so browsers wouldn't accept these certificates so it's worth nothing. It's all just about trust, and I'm not sure I trust Symantec more than I trust you. (And I don't mean I actually trust you, by the way.)
For everyone else it's not really about SSL, security and CAs, it's just about how popular browsers behave.
So, no, monopolies existing for the reason they are allowed to do something are never good. Only if they do it for free.
Actually just read their terms of service, which may as well be summarised as "we issue certificates for entertainment purposes only".
There are certainly other options too: here's my suggestion-
The first time you go to a site where the certificate is one you haven't seen before, the browser should show a nice friendly page that doesn't make a fuss about how dangerous it is, and shows a fingerprint image for the site that you can verify elsewhere, either from a mail you've been sent, and with a list of images from fingerprint servers it knows about that contain a record for that site shown next to it.
Once you accept, it should store that certificate and allow you access to that site without making a big fuss or making it look like it's less secure than an unencrypted site. This should be a relatively normal flow and we should make the user experience accessible to normal people.
It's basically what we do for ssh connections to new hosts.
I believe verification should be done out-of-band, using some other way (e.g. advertising) to transmit the fingerprint to the users. I've used self-signed certificates to collaborate over HTTPS with people I know in real life, and all I do is give them little pieces of paper with my cert printed on them.
The example you give with regards to exchanging a piece of paper is very similar. It's ridiculously hard to do such a thing on large scale without trusting intermediaries.
I'm putting my eggs on certificate pinning.
All this plus something like a notary system to double check all your trusted root keys, would be much better than the hierarchical CA system we have.
It's not interesting why someone hypothetically did get their root keys compromised, it's interesting how the proposed system would cope with it.
(Downvoting the question is not really a web scale way to build a global trust system.)
This is misguided thinking, pure and simple. Because of this line of thinking, your everyday webmaster has been convinced that encrypting data on a regular basis is more trouble than it's worth and allowed NSA (or the Chinese or the Iranian or what have you) authorities to simply put in a tap to slurp the entire internet without even going through the trouble of targeting and impersonating. Basically, this is the thinking that has enabled dragnet surveillance of the internet with such ease.
Encrypted (Certified) COOL GREEN
Encrypted (Self-Signed) EVIL RED
Unencrypted NOTHING / NEUTRAL CHROME
Tell me how the logic works here (for an average user).
( http://wingolog.org/archives/2014/10/17/ffs-ssl )
...it should probably look like this:
Safe against active attacks:
Encrypted (Certified) COOL GREEN
Encrypted (Self-Signed) SCARY ORANGE
Unencrypted EVIL RED
"Neutral Chrome" is the default state of the web -- the site doesn't assert that it should be trusted, and it shouldn't be, and that's the default state people should have in approaching the web.
"Cool Green" is "the site asserts that it has a particular identity and that communication with that identified site is private, and it passes the tests built into the browser's security model to verify all that."
"Evil Red" is "the site asserts that it has a particular identity and that communication with that identified site is private, but it fails the tests built into the browser's security model to verify all that."
Seems to me to be perfectly logical, even if we might prefer a better security model for making and verifying the claims at issue.
Self-signed is a low probability of security.
Signed is a high probability of security.
This continuum makes more sense than the current state of affairs.
If someone forwards encrypted content on behalf of my server, it's called man-in-the-middle attack, and they should not be capable of doing it without the huge red flags.
That would be correct if you could assume that the NSA couldn't fake certificates for websites. But it can, so it's wrong and misleading. It's certificate pinning, notary systems etc. that actually give some credibility to the certificate you're currently using, not whatever the browsers indicate as default.
FWIW, (valid) rogue certificates have been found in the wild several times, CAs have been compromised etc. ...
And it's only going to get worse as SHA-1 become more and more affordable to crack.
But SHA-1 attacks are going to be a huge problem all over our protocol stack :(
PS. nice (presumably political) downvote further up ...
So while the NSA can technically do that, they only get a few shots cause each one has a high chance of burning the CA.
For lesser sites and narrow targets, this may not be true.
It would also have to control the wire for the attack target, but via wire tapping laws that is already a solved problem. Because they control the connection of the attack target, I don't see how the fact that the certificate chain was compromised would ever become public knowledge.
Web of trust was designed to address the central authority weakness, but itself apparently has scalability issues, although I'm unclear on why.
(for the record, I didn't downvote you)
There's nothing stopping the requirements from being "mint us a certificate according to these specs" and additionally "okay, now pin this certificate in your browser".
What prevents an NSL from compelling Google from minting a new certificate (they are a CA), providing the keys to the bad guys, and distributing that certificate in Chrome? NSLs have been used in the past to compel positive action (c.f. Lavabit), so I really don't see how you think there's any practical limit to their power.
My understanding is that there isn't a limit. If I am wrong about this, then kindly reply directly here so we can all learn instead of giving the "read up on" non-answer.
To my knowledge the exact details of the Lavabit case were never released, but from what has been released it's quite clear that the issue was regarding a warrant and a gag order, because the ensuing litigation wouldn't have been remotely applicable to an NSL (otherwise Lavabit's attorney would have won on a walk).
None of this is to say that I think NSLs should exist. In fact, I think they're a terrible idea. But the vast majority of discussions around them and similar topics is so grossly uninformed that it's impossible to take most people seriously on these subjects.
No substantial difference from the concept I'm complaining about.
It occurred to me that this is a really good way of establishing a trust path: while they're only using it to guide you to the right app, they could embed a little public key in there. Then you could authenticate the new printer or fridge by physically being near it.
We'd have to extend our UIs a bit to cover these use cases (it should basically act like a trusted self-signed cert), and probably you only want to trust NFC certs for *.local.
All these appliances should let you change the cert on them, but you still need that initial connection, and at smaller organizations (or households) the certs will never ever be changed.
I used to work on embedded security projects so I care about this; I also realize that's a small portion of the market. I'm okay with making the people connecting to their new printer jump through a hoop in order to reduce the chances of someone hijacking www.paypal.comm but you still have to allow some way in.
Why install a firewall in each device if you can install one on the router that works for everything?
To allow you to create a signed certificate to authenticate it?
Having an FQDN doesn't mean you need to install a firewall on your device. You can still use the router's, and even prevent any inbound connections from the WAN to the device.
Maybe a security-conscious person thinks that, but the typical user does not knowingly choose http over https, and thus the danger of MitM and (unaccepted) snooping is at least as large for the former.
So it's somewhat debatable why we'd warn users that "hey, someone might be reading this and impersonating the site" for self-signed https but not http.
The self-signed cert risk has nothing to do with the NSA... if it's your cert or a known cert, you add it to the trust store, otherwise, you don't.
It's as if a building manager, scared that small amounts of sound can leak through a door, decided that the only solution is to nail all the office doors open and require you to sign a form in triplicate that you are aware the door is not completely soundproof before you are allowed to close it to make a phone call. (Or jump through a long registration process to have someone come and install a heavy steel soundproofed door which will require replacement every 12 months.)
After all, if you're closing the door, it's clearly meant to be private. And if we can't guarantee complete security against sound leaks to people holding their ear to a glass on the other side, surely you mustn't be allowed to have a door.
How would you inform people going to www.mybank.com which is presenting a self-signed cert in a way that a) they clearly notice but that b) doesn't annoy you when you connect to www.myblog.com which also is presenting a self-signed cert?
If the user typed https://www.mybank.com, show the usual warning for self-signed certificates.
But your users won't notice the difference, because they are used to see the certificate warning on his browser.
A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate. At the moment CAs are the best known way to do that (and before anyone brings certificate pinning or WoT, they come with their own problems, please read this comment of mine https://news.ycombinator.com/item?id=8616766).
EDIT: You can downvote all you want but I'm still right.
Each time anyone repeats the "self-signed certificates are still better than HTTP plain text" lie is hurting everyone in the long run.
They're much worse, both for the users and from a security perspective. Self-signed certificates are evil unless you know exactly what you're doing and are in full control of both ends of the communication (in which case just trust it yourself and ignore the warnings).
An opportunistic privacy solution with no legacy installed base to worry about is tcpcrypt:
So if anyone wants to make progress on opportunistic unauthenticated encryption without having to fight about UA behaviors, tcpcrypt may be more fertile ground than self-signed certificates.
How exactly? Did you read my linked comment?
As far as I can tell, self-signed certs are always a no-no. As soon as one is compromised and has to be revoked the whole system breaks apart.
The only situation where a self-signed certificate makes sense is when you control both ends of the communication and can revoke the cert on the client yourself.
In the age of WiFi, you can't dismiss active attacks.
EDIT: Again, whoever is downvoting can downvote all he wants but I'm still right. If I am not, prove it via comments, not downvotes, and we'll be able to discuss each other's views.
Even parent's Tcpcrypt link says it is vulnerable.
> By default Tcpcrypt is vulnerable to active attacks
> Tcpcrypt, however, is powerful enough to stop active attacks, too, if the application using it performs authentication.
How are you going to perform authentication via insecure channels without CAs?
I forgot what the current status of drafts proposing this is. Amazingly, I found that Rohit Khare described a form of this mechanism way back in 1998 (so it's not a super-new concept).
Keys would be exchanged via Diffie-Hellman as usual, but a certificate wouldn't be involved since it's useless anyways (you can't certify anything in such a scheme, why bother at all?) and thus would be vulnerable to active attacks.
Certificates imply long-term authentication. It's an important nuance since they are long-lived by definition, so they have to be trusted and revoked as needed, in which case we're still facing the problem I mentioned earlier.
Trivial? Yes. As trivial as intercepting plain HTTP? No.
The NSA or adversary du jour can vacuum up anything sent over plain HTTP with zero risk. Self-signed HTTPS forces the attacker to commit some resources and, more importantly, run the risk of exposure. Security is not a binary (no encryption scheme is perfect), it's about increasing the cost to attackers.
If we encourage users to blindly accept self-signed certificates (giving us end-to-end encryption but sacrificing identification), nothing would stop those actors from altering your HTTPS sessions as easily as they alter your HTTP sessions today. It's throwing the baby out with the bathwater.
I'm really having trouble figuring out the attack scenario unique to self-signed certificates that you don't have with plain http.
If there's a man in the middle, then they can read the traffic. But others still have a problem.
With HTTP, you know that everyone can read the traffic.
I think unsigned certs, especially with pinning, can be used to make wholesale collection of internet traffic vastly more difficult.
Certificates don't even solve the problem they attempt to solve, because in practices there are too many weaknesses in the chain. When you first downloaded firefox/chrome, who knows that the NSA didn't tamper with the CA list? (not that they'd need to)
Unfortunately, no browsers adopted the project, and it is no longer compatible with Firefox. There are a couple forks which are still in development, but they are pretty underdeveloped.
I wonder if Mozilla would be more likely to accept this kind of project into Firefox today, compared to ~4 years ago when it was first released, now that privacy and security may be more important topic to the users of the browser.
That's what PGP/GPG people seem to do, anyway.
Why can't I get my personally-generated cert signed by X other people who vouch for its authenticity?
Well... that's true regardless, as the NSA almost certainly has control over one or more certificate authorities.
But I agree with the sentiment. :)
Nah. The NSA, or any adversary remotely approaching them in resources, has the ability to generate certificates that are on your browser's trust chain. Self-signed and unknown-CA warnings suggest that a much lower level attacker may be interfering.
We do have a solution that does accept self-signed certificates. The remaining pieces need to be finished and the players need to come together though:
If you're in San Francisco, come to the SF Bitcoin Meetup, I'll be speaking on this topic tonight:
Let's Encrypt seems like the right "next step", but we still need to address the man-in-the-middle problem with HTTPS, and that is something the blockchain will solve.
That being said: Identity verification is important as the encryption is worthless if you can be trivially man-in-the-middled. All encryption assures is that two end points can only read communications between one another, it makes no assurances that the two end points are who they claim to be.
So verification is a legitimate requirement and it does have a legitimate cost. The problem is the LOWEST barriers to entry are set too high, this has become a particular problem when insecure WiFi is so common and even "basic" web-sites really need HTTPS (e.g. this one).
HTTP can be man-in-the-middled passively, and without detection; making dragnets super easy.
In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what public key was used. The content provider can have a process that sits on top of a VPN / Tor that periodically requests a resource from the server and if it detects that the service is being MITM then it can shut down the service and a certificate authority can be brought in.
Edit: Also, all this BS about how HTTPS implies security is besides the grandparent's point: certificates and encryption are currently conflated to the great detriment of security, and they need not be.
Nothing can be man-in-the-middled passively, that makes no sense. That isn't what a MitM is. It requires active involvement by its very nature.
> In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what public key was used.
I genuinely don't understand what you're trying to say.
> The content provider can have a process that sits on top of a VPN / Tor that periodically requests a resource from the server and if it detects that the service is being MITM then it can shut down the service and a certificate authority can be brought in.
If the MitM originates from a specific location (e.g. a single Starbucks, a single hotel, an airport, etc) it would never be detected by that method.
> Also, all this BS about how HTTPS implies security is besides the grandparent's point: certificates and encryption are currently conflated to the great detriment of security, and they need not be.
Only MitM protections AND encryption provide a secure connection when together. Individually they're insecure.
If someone wants to come up with a security scheme which doesn't depend on certificates that would be fine. You just have to solve the encryption issue (easy) and the identity issue (hard).
By this I mean record all form submissions done through HTTP.
>> In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what public key was used.
> I genuinely don't understand what you're trying to say.
The default thing we're trying to prevent is someone close to the server MITMing every request, recording each post, and reenacting them so that they are not discovered.
> If the MitM originates from a specific location (e.g. a single Starbucks, a single hotel, an airport, etc) it would never be detected by that method.
That is true for the example I gave which is just a proof-of-concept, but not true for a better method, like decentralization + public key signing.
What I'm fundamentally saying is that Cert + HTTPS is more secure, but it is not fully secure, since you have to trust the cert provider. Just in the same way, HTTPS without cert is not fully secure, but it is (much) more secure than HTTP.
"eavesdropped" is the word you're looking for.
Deployments in the wild appear to use cable splitters to read, so often have no direct write access due to transport layer limitations and sometimes deliberate "Data Diode" one-way firewalls on the hot pipe (just in case?); they communicate with instrumented boxes closer to 'home' on a management network, which do not have to be on-path themselves, some of which may well be hacked routers, to do packet injection. C&C was centralised pingbacks, but that lost races (typical latency: 670ms-ish) so is now distributed (with QUANTUMFIRE).
They can use that knowledge and capability together to race to control a TCP connection, after which the real packets will be discarded by the target endpoint (because the seq is "wrong"), after which they are fully man-in-the-middle and can inject redirection headers (QUANTUMINSERT), tracking cookies (QUANTUMCOOKIE) or infect downloaded executables (QUANTUMCOPPER); they can also inject RSTs to force TCP connection resets (QUANTUMSKY; also used by Blue Coat, the .cn Golden Shield, and many others).
Note this implies that they are detectable and locatable, if you know what to look for.
(Sorry I can't be much more helpful without going in and taking one, and I think they would very strongly disapprove of that. <g>)
For example, in an individual user situation, if the "CA" is a mac user, you use a local exploit, and export the private key from the Keychain. Done.
Most of the time, I'm much more interested in a domain identity than a corporate identity. If I go to bigbank.com, and is presented with a certificate, I want to know if I am talking to bigbank.com -- not that I'm talking to "Big Bank Co." (or at least one of the legal entities around the world under that name).
Therefore it would make much more sense if your TLD made a cryptographic assertment that you are the legal owner of a domain and that this information could be utilized up the whole protocol stack.
That would not have a legitimate cost, apart from the domain name system itself.
What's especially baffling about self-signed certificate advocacy is the implied threat model. Low- and mid-level network attackers and crime syndicates can't compromise a CA. Every nation state can, of course (so long as the site in question isn't public-key-pinned). But nation states are also uniquely capable of MITMing connections!
Could you elaborate here? With a self-signed cert, the server is still not sending secret information in the first few packets; it just tells you (without authentication) which public key to use to encrypt the later packets (well, the public key to encrypt the private key for later encryption).
The threat model would be eavesdroppers who can't control the channel, only look. Using the SS cert would be better than an unencrypted connection, though still shouldn't be represented as being as secure as full TLS. As it stands, the server is either forced to wait to get the cert, or serve unencrypted such that all attackers can see.
I think the CA system by itself is inadequate, but unlike unauthenticated TLS, actually does provide some security.
First, TLS has three principles that, if you lose one, it becomes essentially uselsss:
1) Authentication - you're talking to the right server
2) Encryption - nobody saw what was sent
3) Verification - nothing was modified in transit
Without authentication, you essentially are not protected against anything. Any router, any government can generate a cert for any server or hostname.
Perhaps you don't think EV certs have a purpose - personally, I think they're helpful to ensure that even if someone hijacks a domain they cannot issue an EV cert. Luckily, the cost of certificates is going down over time (usually you can get the certs you mentioned at $10/$150). That's what my startup (https://certly.io) is trying to help people get, cheap and trusted certificates (sorry for the promotion here)
Also, active attacks (like MITM) are harder to do and easier to detect than passive attacks (snooping).
BTW what you call "dragnet surveillance" is better described as "Pervasive Monitoring", see also RFC7258 "Pervasive Monitoring Is an Attack" .
But it's not like MITM attacks are not real. CAs don't realistically do a thing about them, but it is true that you can't trust that your connection is private based on TLS alone. (unless you're doing certificate pinning or you have some other solution).
Our hope is that Let's Encrypt will reduce the barriers to CA-signed HTTPS sufficiently, that it will become realistic for browsers to show warning indicators on HTTP.
If they did that today, millions of sites would complain, "why are you forcing us to pay money to CAs, and deal with the incredible headache of cert installation and management?". With Let's Encrypt, the browsers can point to a simple, single-command solution.
The next step will be to replace the CA system with something actually secure, but that comes after we move the web to a place where most websites are at least trying.
Back in the Netscape days, it did. People got tired of clicking OK every time they searched for something.
Site: Here's my public key. Use it to verify that anything I sent you came from me. But don't take my word for it, verify it against a set of trusted authorities pre-installed on your machine.
Browser: Ok, your cert checks out. Here's my public key. You can use it for the same.
Site: Ok, now I need you to reply this message with the entire certificate chain you have for me to make sure a 3rd party didn't install a root cert and inject keys between us. Encrypt it with both your private key and my public key.
Browser: Ok, here it is: ASDSDFDFSDFDSFSD.
Site: That checks out. Ok, now you can talk to me.
This is what certificates help with. There are verification standards that apply, and all the certificate authorities have to agree to follow these standards when issuing certain types of SSL certificates. The most stringent, the "Green bar" with the entity name, often require verification through multiple means, including bank accounts. Certificate authorities that fail to verify properly can have their issuing privileges revoked (though this is hard to do in practice, it can be done).
"Your certificate is due to expire.
If your certificate expires, your site will no longer be encrypted."
Just blatantly false.
Of course, we know that's not true either, but try explaining to your visitors how to bypass the security warning (newer browsers sure don't make it obvious, even if you know to look for it).
There are trusted free certificates as well, like the ones from StartSSL.
> if a bank pays 10,000 bucks for a really cool verification, they get a giant green pulsating URL badge
Yeah, $10 000 and legal documentation proving that they are exactly the same legal entity as the one stated on the certificated. All verified by a provider that's been deemed trustworthy by your browser's developers.
Finally, if a certificate is self-signed, it generally should be a large warning to most users: the certificate was made by an unknown entity, and anybody may be intercepting the comunication. Power-users understand when self-signed CAs are used, but they don't get scared of red warnings either, so that's not an issue.
But a man-in-the-middle attack will remove any secrecy encryption provides and to prevent that, we require certificate authorities to perform some minimal checks that public keys delivered to your browser are indeed the correct ones.
You've got a point about how warnings are pushing incentives towards more verification, but they serve a purpose that aligns with secrecy of communication.
Running a CA has an associated cost, including maintenance, security, etc. That's what you pay for when you acquire a certificate. Whether current market prices' markup is too high would be a different question, but paying for a certificate is definitely not spending 200$ to look cool.
CAs are the best known way (at the moment) to authenticate through insecure channels (before anyone brings pìnned certs or WoT, read this comment of mine: https://news.ycombinator.com/item?id=8616766)
EDIT: You can downvote all you want but I'm still right. Excuse my tone, but slandering a system without an intimate understanding of the "how"s and the "why"s (i.e. spreading FUD) hurts everyone in the long run.
Downvote sprees without an explanation detract from healthy discussion since they basically mean "I'm so mad about how wrong you are that I don't even care about why you think you are right".
I guess I'll just ignore them...
This is huge if it takes off. The CA PKI will no longer be a scam anymore!!
I'd trust the EFF/Mozilla over a random for profit "security corporation" like VeriSign any day of the week and twice on Sunday to be good stewards of the infrastructure.
OK, that's a little awkward. A browser extension could automate this. But in practice, nobody wants to do this, because hardly anyone has opinions on particular CAs. It's a sort of meta-opinion - some people feel strongly they should be able to feel strongly about CAs, but hardly anyone actually does. So nobody uses such browser extensions.
On Firefox it's preferences -> advanced -> certificates -> view certificates.
Users have a clear stake in whatever informational exchange occurs between them and the websites we access. We should have the authority to participate in determining the terms on which that exchange is secured.
But syncing which certificates to delete is probably a much harder sell.
At least there's a way to do programmatically:
apt-get install libnss3-tools
certutil -d /home/$USER/.mozilla/firefox/$FIREFOX_PROFILE -D -n $TARGET_CA_NAME
Unfortunately, it couldn't on Chrome, because you can't even access a page's certificate from an extension in Chrome:
And Firefox's certificate API is not much better, only passive access without ability to block connections if you detect an unwanted cert.
Nope. Firefox's Addon API lets you do pretty much whatever you want. It might be kind of hard and annoying, but you can certainly block connections that are signed by an untrusted CA. How do you think Convergence  worked?
So with Firefox, you could build the kind of add-on described by Mike.
But I have confirmed for myself Chrome extension API's lack of ability to even read the certificate of a current page. Chrome may be able to read block page loads (don't know, haven't checked) but without being able to even view a cert, it doesn't do much good.
Incidentally, I can also add my own CA.
This new SSL scheme is mostly security theater. There's no particular reason to encrypt traffic to most web pages. Anyone with access to the connection can tell what site you're talking to. If it's public static content, what is SSL protecting? Unless there's a login mechanism and non-public pages, SSL isn't protecting much.
The downside of SSL everywhere is weak SSL everywhere. Cloudflare sells security theater encryption now. All their offerings involve Cloudflare acting as a man-in-the-middle, with everything decrypted at Cloudflare. (Cloudflare's CEO is fighting interception demands in court and in the press, which indicates they get such requests. Cloudflare is honest about what they're doing; the certificates they use say "Cloudflare, Inc.", so they identify themselves as a man-in-the-middle. They're not bad guys.)
If you try to encrypt everything, the high-volume cacheable stuff that doesn't need security but does need a big content delivery network (think Flickr) has to be encrypted. So the content-delivery network needs to impersonate the end site and becomes a point of attack. There are known attacks on CDNs; anybody using multi-domain SSL certs with unrelated domains (36,000 Cloudflare sites alone) is vulnerable if any site on the cert can be broken into. If the site's logins go through the same mechanism, security is weaker than if only the important pages were encrypted.
You're better off having a small secure site like "secure.example.com" for checkout and payment, preferably with an Extended Validation SSL certificate, a unique IP address, and a dedicated server. There's no reason to encrypt your public product catalog pages. Leave them on "example.com" unencrypted.
Regarding the rest of your post, however, I'm calling bullshit. You give very bad advice. Deploy TLS on every website. Deploy HTTP Strict-Transport-Security wherever you can.
The sites people visit are confidential, and yes, are not protected enough at the moment. (That will eventually improve, piece by piece.) That's absolutely no excuse at all for you not protecting data about the pages they're on or the specific things they're looking at, even if your site is static, or not protecting the integrity of your site. You have no excuse for that. Go do it.
Regarding your CDN point, kindly cite - or demonstrate - your working "known attack" against Cloudflare's deployment?
Black Hat 2009, "Why TLS Keeps Failing to Protect", Moxy Marlinspike, slide 42:
1) find target site A with shared SSL cert. Cloudflare gets shared SSL certs with 50+ unrelated domains.
2) find vulnerable server B in a domain on same cert. (Probably Wordpress.)
3) attack server B, inserting fake copy of important pages on site A with attack on client or password/credit card interception.
4) use DNS poisoning attack to redirect A to B.
All it takes is one vulnerable site out of the 50+ on the same cert.
The whole shared-cert thing is a workaround for Windows XP. Cloudflare does it because they're still trying to support IE6 on Windows XP, which doesn't speak Server Name Identification, and they don't have enough IPv4 addresses to have one per customer.
5) Cloudflare's sni??????.cloudflaressl.com presents an error to you because the Host: header is either missing, doesn't match the SNI, or otherwise, serves the correct site to you instead of your phishing page.
You obviously haven't tested this. And it's Moxie.
Vhost-confusion is a relevant attack on TLS with non-HTTP protocols, HTTP/0.9 and sites which serve a default domain to clients with no Host: headers. Cloudflare quite specifically does none of these, and is not vulnerable in its deployment - it needs the Host: header to know which site you want it to select with its reverse-proxy, and you can't poison that because it's protected by TLS to Cloudflare.
Also you, the attacker, don't have the cert.
If you can DNS poison away from Cloudflare, please report it to their security team, but you'll find they're looking at deploying DNSSEC soon.
Off the top of my head:
It protects people/companies from having their reputations ruined by a MITM attack that replaces content on their site with something offensive.
It protects sensitive/important content on sites from being tampered with by an attacker. For example, if I am hosting a binary for download I can make a signature available for that binary on my site. In order for the signature to serve its purpose the user needs to be sure it hasn't been modified en route.
HTTPS encrypts the URL paths you access . Would you rather an adversary knew which IPs you visited, or the IPs plus the URLs?
I do think behind-the-CDN interception, in-front-of-the-CDN compromises, and weak CDN crypto are all serious concerns. I won't name any names here, but the employment histories of major CDNs' security team members definitely deserve closer scrutiny by civil society groups and reporters, especially those interested in fighting mass surveillance.
But overall, I think it's important to respect the privacy and security of users first, and work toward solving the engineering problems that need to be solved in order to affirm that commitment to users, as these folks have tried to do.
In this case, SSL protects against MITM attacks. If a customer goes to the unencrypted "example.com" site and gets a bunch of ads for porn, it will give the customer a negative impression of the company. All it would take is a few pitchfork-wielding high-profile twitter accounts to cause a PR nightmare. Even if the cause is a hacked coffee shop wireless access point, it may be hard to restore public opinion.
That scenario is a long-shot, but in my opinion, the potential negative consequences outweigh the time and energy required to set up SSL (especially since a basic SSL certificate is free).
From where? StartSSL only gives out free certs to individuals. For my company, they've actually required me to get organizational validation in the past, which wasn't cheap ($200, IIRC—$100 for the organizational validation, plus $100 for stage 2 personal validation, which also required me to upload images of my driver's license and passport).
Even so, I'd argue that $200 is a fairly cheap way to protect the integrity of your company.
Their FAQ alludes to this, but doesn't really make it explicit:
> The certificate is for my company, what shall I do?
> In the Class 1 settings (free), the only possible relationship between StartCom and the subscriber is
> with individuals, i.e. natural persons. StartCom has no relationship with the organization a subscriber
> may represents and acknowledges only the subscriber. All responsibilities according to the StartCom
> CA Policy are that of the subscriber personally, even in case he/she decides to obtain certification as
> an employee or representative of an organization.
> Organizations should perform Class 2 validation and an organization name may only appear in a digital
> certificate at Class 2 level and higher.
https:// helps protect the act of participation and deters the building of dossiers.
Its the difference between the books in the library and the list of books in the library you have read.
how about the SPDY protocol and the faster speed it offers?
Of course this is true in theory, but in practice, both clients and customers get 'warm fuzzies' from seeing that green lock in the URL window.
It let's them 'know' that the company they are dealing with is at least somewhat reputable. Whether this is true or not doesn't matter; it is the perception many people have, and it does affect sales numbers in the real world.
"A recovery token is a fallback authentication mechanism. In the event that a client loses all other state, including authorized key pairs and key pairs bound to certificates, the client can use the recovery token to prove that it was previously authorized for the identifier in question.
This mechanism is necessary because once an ACME server has issued an Authorization Key for a given identifier, that identifier enters a higher-security state, at least with respect the ACME server. That state exists to protect against attacks such as DNS hijacking and router compromise which tend to inherently defeat all forms of Domain Validation. So once a domain has begun using ACME, new DV-only authorization will not be performed without proof of continuity via possession of an Authorized Private Key or potentially a Subject Private Key for that domain."
Does that mean, if for instance, someone used an ACME server to issue a certificate for that domain in the past, but then the domain registration expired, and someone else legitimately bought the domain later, they would be unable to use that ACME server for issuing an SSL certificate?
The previous issuing CA should have revoked the cert they issued when the domain was transferred. But a CA speaking the ACME protocol might choose to look at whois and DNS for additional information to decide whether it issues different challenges in response to a certification request.
An interesting thing happened at a meet-up at Square last year. Someone from google's security team came out and demonstrated what google does to notify a user that a page has been compromised or is a known malicious attack site.
During the presentation she was chatting about how people don't really pay attention to the certificate problems a site has, and how they were trying to change that through alerts/notifications.
After which someone asked that if google cared so much about security why didn't they just become a CA and sign certs for everyone. She didn't answer the question, so I'm not sure if that means they don't want to, or they are planning to.
What privacy concerns should we have if someone like goog were to sign the certs? What happens if a CA is compromised?
There aren't a whole lot of privacy concerns with CA's as long as you use OCSP stapling, so users browsers aren't hitting up the CA each time they visit a website (Chrome never does this but other browsers can do).
Re: CA compromise. One reason running a CA costs money is that the root store policies imposed by the CA/Browser Forum require (I think!) the usage of a hardware security module which holds the signing keys. This means a compromised CA could issue a bunch of certs for as long as the compromise is active, but in theory it should be hard or impossible to steal the key. Once the hackers are booted out of the CA's network, it goes back to being secure. Of course quite some damage can be done during this time, and that's what things like Certificate Transparency are meant to mediate - they let everyone see what CAs are doing.
That's something imposed by the audit criteria (WebTrust/ETSI). What you detailed is also why roots are left disconnected from the internet - if you compromise an intermediary, that can be blacklisted as opposed to the entire root.
These are the things you pay for when you buy a certificate from a CA. In fact, I would be 100% opposed to obtaining my website's cert from a CA if it were free-of-charge, because I know good physical security is expensive. However, I already trust the EFF and the Umich researchers (and their assurances of physical security), so I'm absolutely happy with obtaining a free certificate from them.
While probably not officially scriptable, free certificates have been available since a long time ago: https://www.startssl.com/?app=1
Also, no free wildcard certs. Which I really want.
> What happens if a CA is compromised?
Looking at past compromises, if they have been very irresponsible they are delisted from the browsers' list of trusted roots (see diginotar). If they have not been extremely irresponsible, then they seem to be able to continue to function (see Comodo).
NB: This is a bit unfair, because the existing for-money CAs haven't always stopped someone from registering microsoft.com.
1. Over the wire encryption (which this handles)
2. As a bad, but the best we've got site identification system for stopping phishing mechanism.
Currently, for even the cheapest certs (domain+email validated) - the CAs will reject SSL cert requests for anything that might be a phishing target. Detecting "wellsfargo.com" is pretty easy, where it gets tricky is things like "wellsforgo.com", "wellsfàrgo.com" etc. Which if I'm looking at this right will just sail through with LetsEncrypt.
I suspect we're going to actually end up with two tiers of SSL certs as the browser makers have started to really de-emphasize domain validated certs  like this vs the Extended Validation (really expensive) certs, to the point where in most cases now having a domain cert does not know green (and maybe doesn't even show a lock) at all.
As a side note, Google had announced that they were going to start using SSL as a ranking signal  (sites with SSL would get a slight bump in rankings), from this perspective the "high" cost of a cert was actually a feature as it made life much more expensive on blackhat SEOs who routinely are setting up hundreds of sites.
1 - Screenshots: https://www.expeditedssl.com/pages/visual-security-browser-s...
2 - http://googlewebmastercentral.blogspot.com/2014/08/https-as-...
There have been previous attempts, e.g. http://www.cacert.org/
AFAIK they failed in the politics front (getting accepted in mainstream browsers). Sounds like EFF might have better leverage.
There are very few companies out there that are okay with serving 1/5th of their potential customers an error page, and for good reason.
A quick glance over EU countries reveals that more than 91% of potential users support SNI.
It might depend on your line of business but I think for some entities this might be a viable option
There are a few other vendors that I've seen offer similar services.