Free CA? This is cool. Why this wasn't done a long time ago is beyond me. (Also please support wildcard certs)
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?
It wasn't done a long time ago because running a CA costs money (which is why they charge for certificates), so whoever signs up to run one is signing up for a money sink with no prospect of direct ROI, potentially for a loooooong time. This new CA is to be run by a non-profit that uses corporate sponsorship rather than being supported by the market; whether that's actually a better model in the long run is I suppose an open question. But lots of other bits of internet infrastructure are funded this way, so perhaps it's no big deal.
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.
Your mileage may vary, but the biggest upfront cost is the WebTrust audit. Certly got quoted $150k for a reasonable root and its subordinates. This is a yearly cost. HSMs are not cheap either, plus you have to host them securely, hire validation staff, etc...
Ensuring physical security of CA private keys is expensive. This requires things like sturdy padlocks, closed-circuit security cameras, and up-to-date hardware and software.
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.
.... also, you need multiple people in the organisation, you typically need to write your own infrastructure for vending certs, billing, you need to run OSCP responders and perhaps CRLs so clients can check if the cert was revoked, that can take a lot of bandwidth, then you need support staff because when people are paying, they expect support, etc.
> imposed by the CA/Browser Forum require (I think!)
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.
You raise a good point though, SSL/TLS Certs are trying to deal with two separate problems:
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 [1] 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 [2] (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.
If you can make microsoft.com serve up the correct challenge response, you'll be able to get a cert for them issued by the this project. This isn't a pure rubber-stamping service.
If each domain name can get a non-wildcard cert for free, quickly, why do you need wildcard certs? For multi-subdomain hosting on one server? Just wondering.
For my previous use cases, it's ideal for dynamically created subdomains of a web application. If I know ahead of time, it's easy to grab a cert for any subdomain. However if a user is creating subdomains for a custom site or something similar, it's much nicer/easier to have the wildcard cert.
The lets-encrypt demo makes it look like you could easily script cert acquisition for new subdomains. And the CA domain validation appears to be totally automated (and fast).
Lots of services create dynamic subdomains in the form of "username.domain.com". To offer SSL on those domains without a wildcard certificate, you'd need to obtain a new certificate and a new IPv4 address every time a user signs up. You also need to update configuration and restart the web server process.
I think the issue of whether or not there should be a wide new industry borne on the back of the CA architecture, its all a bit of a red-herring, anyway. This is only security at the web browser: do we trust our OS vendors to be CA's, too? If so, then I think we may see a cascade/avalanche of new CA's being constructed around the notion of the distribution. I know for sure, even if I have all the S's in the HTTP in order, my machine itself is still a real weak point. When, out of the box, the OS is capable of building its own certified binaries and adding/denying capabilities of its build products, inherently, then we'll have an interesting security environment. This browser-centric focus of encryption is but the beachhead for more broader issues to come, methinks; do you really trust your OS vendor? Really?
> Why this wasn't done a long time ago is beyond me.
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).
Google is a CA, and they sign their own certs as "Google Internet Authority G2" under SHA fingerprint BB DC E1 3E 9D 53 7A 52 29 91 5C B1 23 C7 AA B0 A8 55 E7 98.
They're subordinate under another CA (GlobalSign), and presumably contractually obligated to only sign their own certs. GlobalSign offers the following service to anyone willing to pay the sizable fee, undergo a sizable audit, comply by the CA/Browser forum rules, and only issue certs to themselves:
No way I am running something like this on a production machine.
I like the idea but I would rather have the client just output the certificate and key in a dir so I can put the files where I need them and I can configure the changes to my webserver.
Also this does not solve the issue of a CA issuing certificates for your domain and doing MITM.
This is just a pre-announcement to let folks (OSes, hosting providers, other platforms) plan and do integration work. Per our own warnings, we definitely don't want this running on production machines until it launches in 2015.
Our Apache code is a developer preview, we'll be working on Nginx next.
ISRG will be operating a new root CA for this project. Although if you think that your choice of CA makes you more or less secure, you may not have understood how PKIX works -- you can buy a cert from whichever CA you like, but your adversary can always pick the weakest one to try to impersonate you.
> ISRG will be operating a new root CA for this project.
Are you going to be cross-signed by IdenTrust or something? If you're really going to try and create a new root CA from scratch, surely you will be impaled on the spike of low coverage for many years?
"ISRG will be operating a new root CA for this project."
Does that mean every client/browser will need to be updated to include the new CA? Or will it somehow be signed by other (competing) CAs?
I like the idea of this project, and I think it's a great thing for the Internet - I just worry that it will take a long time for it to be usable in practice.
"This code intended for testing, demonstration, and integration engineering with OSes and hosting platforms. Currently the code works with Linux and Apache, though we will be expanding it to other platforms."
For those who are wondering why sschueller is saying such things (when I first read his comment my reaction was "how the f* could this be limited to Apache?", which worried me since I mostly use lighttpd), see the How It Works page [1] of Let's Encrypt.
> I would rather have the client just output the certificate and key in a dir
I'm sure they'd support "manual setup". Not many sites would opt into running their software agent (yet). I'm expecting the client to come with a lot more benefits than "simple setup", though.
I think that plenty of site admins will be happy to run this software agent—remember, there are many site admins right now that aren't even bothered to set up TLS at all.
I run plenty of tools right now on production boxes that I personally haven't fully audited—we all do. This tool should be simple and widely used enough that it will be trustworthy.
For the cautious, it would be nice if the tool offered a mode that could be run as a normal user, even on a different machine. It'd have to be an interactive process:
1. "Enter domain to be signed."
2. "To validate ownership of the domain, create a TXT record on xxx.example.domain with 'na8sdnajsdnfkasdkey' as the value."
3. "Domain ownership has been validated. Please paste the CSR."
4. "The zone has been signed. Here is your certificate:"
Much less convenient (basically the same as the process with current CAs), but it would allow security-conscious admins to use the CA in a way that is comfortable for them. Since the tool is open source, it should be fairly easy for someone to write their own tool that speaks to the CA while providing this interactive process.
The tool is interesting and to be honest, I'll be comfortable using it (I'm not running anything high-profile or sensitive). However, the real news here is the new CA—the tool is merely a convenience.
ACME is a protocol for securely and automatically issuing certificates. Presumably Apache, Nginx, IIS and any other web server could take advantage of it.
They are creating a new CA for this purpose.
I can't imagine this will replace the manual learn-pay-experiment-error-success process we have at the moment, so experts will still be able to control the process manually.
It doesn't address CA MITM attacks but it does significantly reduce non-CA MITM attacks by remove the two primary objections to deploying SSL: cost and complexity. Bravo EFF - this could be the most significant step in SSL adoption ever.
We're putting out a protocol for requesting certs and validating domain control (that our new CA will support -- and we'll be cross-signed to work in all mainstream browsers) and we've already written a client for it that integrates with Apache and can edit your Apache config.
If you're comfortable editing your own Apache configs, then you'll only need to use the client to obtain the cert and not to manage its installation long-term. (The client does need to reconfigure the web server while obtaining the cert as part of the CA validation process.)
The protocol is openly published, so you can write your own client too, or follow the protocol steps manually -- or any web server developer or hosting platform can develop their own alternative client.
There does need to be some client to speak the protocol, but there's no attempt to force you to use it to manage your certs and configs if that's not what you want. The convenience is aimed at people who don't understand how to install a cert, or who think that process is too time-consuming.
People could think they are reading an article from your site but actually they're not or the text was tampered with. With https you ensure people are actually reading what you published.
Sure! If I trust your site but not my ISP, then https allows me to trust the connection between us. That means that nobody can tamper with the content and inject some malicious JS. Also, the ISP could only tell that I am talking to your server, and not anything beyond that.
Note that the Verizon issue isn't anything entirely content altering but someone who lives in a country with strict monitoring of traffic could easily change the wording of your website to match their propaganda if you aren't using HTTPS.
So yes, your content is publicly available free stuff and no one is probably sending you user login credentials or credit cards but it still matters.
Is there any reason why I would want to use https for this use case?
Yes it can help you stop:
ISPs inserting adverts into your content (this has happened)
Governments censoring your content or rewriting it
Governments putting people in jail for reading your publicly available (in your country) content, which is illegal in theirs
People impersonating your website
But if you don't want to use it, that's cool too. I suspect all websites will be encrypted at some point soon though, the disadvantages are getting less and less important.
>Governments putting people in jail for reading your publicly available (in your country) content, which is illegal in theirs //
How does that work, surely the gov can still see people accessing the information by monitoring network traffic and the info itself is still public. HTTPS doesn't encrypt the actual request traffic does it, and in any case the gov would still see which server the traffic is going to unless you're using something like tor [and possibly still then].
"User X browses Wikipedia articles about topics A, B, C"
where topics A, B, C could be anything user X doesn't want people recording them reading about: for instance, various political articles, articles about mental illness, articles about LGBT issues, etc. Fill in the blanks.
I use this example myself quite a bit, although we've also got to figure out the distinguishability from page sizes issue. Different Wikipedia pages are different sizes, and they're still different sizes when they're encrypted.
One interesting idea I heard from someone recently is tuning compression so that you target a small number of total page sizes -- rather than padding to expand pages to the same sizes, just don't compress them all quite as well as you could have.
I use this example myself quite a bit, although we've also got to figure out the distinguishability from page sizes issue. Different Wikipedia pages are different sizes, and they're still different sizes when they're encrypted.
Both GnuTLS[1] and Nginx[2] have length hiding implemented. But AFAIK OpenSSL doesn't have it yet, so most users are still left in the dark.
Thanks, I didn't realize that process was so far along!
It might still be challenging to get large sides to adopt padding that will increase the amount of traffic they send (of course, the idea of reducing the efficiency of compression has the same net effect). But it's great to know that there's already a tool in place for traffic padding, at least in some implementations.
However, you can figure out what pages on a large public site like Wikipedia people are reading over HTTPS, based on statistical traffic analysis, because you can see the size of the request, page, and each of the images. Combined with link following analysis, you can make a fairly accurate guess as to what people are reading.
I believe that the combination of HTTP/2 and TLS length-hiding makes that attack impractical. Though admittedly we're still years away from widespread deployment of those two technologies.
Honestly, you're probably not going to get a large personal benefit from this. The larger good is that you'll be helping move the Internet toward encrypted-by-default, which is an enormous societal benefit.
Like you, I don't host any private or remotely sensitive information. I'm encrypting my site because I think it's the right thing to do, even though there's little personal return on investment.
Wow, I had a goofy idea a few months ago that one day we could have some sort of non-profit/charity that just runs a free, as in beer and freedom, "common good" CA.
The "How It Works" page, https://letsencrypt.org/howitworks/, has me a bit worried. Anytime I see a __magic__ solution that has you running a single command to solve all your problems I immediately become suspicious at how much thought went into the actual issue.
If I'm running a single web app on a single Ubuntu server using Apache then I'm set! If I'm running multiple web apps across multiple servers using a load balancer, nginx on FreeBSD then...
All the same I'm really looking forward to this coming out, it can be nothing but good that all of these companies are backing this new solution and I'm sure it'll expand and handle these issues as long as a good team is behind it.
That wouldn't be safe, because then they would have access to your private key and impersonate you. Having you (indirectly via their script) generate the key and submit the public key for signing means your private key never leaves the premises.
The tool will gather the domains, use the CA API to validate ownership, obtain the certs (which cannot be unilaterally created since they are based on a public/private key pair) and manage their expiry.
It's primarily because of the interactive challenge to prove that you control the domains you're requesting the cert for.
If you want, the client can just give you the cert at the end instead of installing it. In the common case for a user who's not currently comfortable with the process, the client is automating several things -- generating a private key and CSR, proving control of the domain, and installing the key and cert in the server.
It would be really helpful if your how it works page explained in detail how it works, in particular that all browsers are covered, that a key and csr are generated, the certs recd, and that the private key never leaves the server (I'm assuming that at present).
My dream cli tool would just generate key, get certs, and dump them in the dir of my choice. The server config is nice to have but not really essential or the hard part.
Really looking forward to seeing this happen, is there any beta program at present?
Generate key, Generate CSR, Send CSR, Receive Certs from CA, Verify ownership, Install certs
Presumably their command line client creates the key, the CSR, sends the CSR, then gets back the certs (at least I'd hope so). I'd be happy to use a vetted command line utility which did that, or even just parts of that process, if I were sure the private key were not transmitted. It's just automating stuff which with current CAs needs to be done manually.
It doesn't seem as magical when you drill down. And if you roll your own nginx or whatever, it'll be less transparent still. But yeah, someone like Ubuntu or Red Hat could enable this on their product that simply.
Domain validation is done through a challenge (issued by a CA) to sign arbitrary data and put on a URL (covered by the domain) the CA can then query. This seems pretty solid. Better then email.
I run Apache httpd, and there's no way I'd let a wizard anywhere near my configuration files or private keys, much less run it on a production server.
I think it's about time for a free CA that is recognized by all clients, but you still need to establish a trust chain to exchange a CSR for a signed certificate. This service needs to be server agnostic. The barrier to adoption isn't configuration, and HTTPS isn't the only thing that uses certificates.
There are lots of different barriers to adoption. With this project we are attacking several of them at the outset, including the cost of obtaining a certificate, and the inconvenience or difficulty of obtaining and installing it for users who don't do that every day.
Because of the open protocol we also aspire to support users with more complex configurations and requirements, who are absolutely welcome and encouraged to write their own implementations of the protocol and integrate with their own existing certificate management and configuration methods. If you think of other barriers to adoption that we can help with, please let us know and we'll try to address them; if you just want our certs for free, please get them and enjoy!
My concern is that your reach is too far. Asking domain administrators to trust your software to manipulate private keys (and server configurations) is as troubling as asking end users to click past security warnings. The whole purpose of the CSR is to obtain the signed certificate without putting the private key at risk. This decoupling isolates the challenge of identity verification in a reasonable place (nobody is saying it's easy). With your client, you're essentially telling people you accept checks or credit cards, but only if they show you their gold. It sets a bad precedent.
I do want your certs for free! But I also want/need to trust you and know that you're following best practices, not just with me but with everyone.
Oh, our software does NOT send the private key to the CA. Never never never never. The point of having it manage the keys is not to give us access to them, it's to be convenient for the end-user, on the end-user's own system, under the end-user's control.
You can tell because our software is open source, written in Python.
We expect the users to get this software from their operating system repos, like from the Debian package repository -- the very same place they get their Apache or Nginx packages. We are not asking people to get the software directly from us, or to use it without being able to read it and check that it's safe and does what they want.
Edit: And if you want to implement your own client, we encourage you to do that -- the more clients the merrier!
I'd still be more comfortable if the process never went anywhere near the private key (and I'm concerned that a proprietary competitor or look-alike would prey on naive users by leveraging your example). But I also applaud your effort and transparency. I admit I trust openssl to manage my own keys and certificates, and there is definitely room in this space for improvement and alternative approaches. But it does sadden me that we risk making administrators as trusting and ignorant of the underlying principles as end users already are today.
Yes, this will only hit the common small-site case. Hopefully if you're running "multiple web apps across multiple servers using a load balancer" you will have the skill to configure HTTPS properly for that situation, which will probably involve custom configuration on the load balancer. It's not a criticism of something trying to solve the common case, where the common solution up until today is pretty much "just forget about it", that it doesn't work at "cloud scale".
What you're seeing today is demos, not the software in its final form. You're also seeing it demo'd with a focus on the most simple usage. There are, and will be, advanced options.
We'll be doing quite a bit of work based on user feedback between now and when we go live. We're well aware that we need to cater to a variety of types of users.
Those free certs will encrypt from the browser to CloudFlare's CDN. You still need to do something to encrypt from CloudFlare to the publishing webserver. Self-signing can work for that hop, though Let's Encrypt may wind up being smoother for sys admins.
We've been working with CloudFlare to drive HTTPS adoption, and plan to work with them further on integration.
This is awesome! It looks like what CACert.org set out to be, except this time instead of developing the CA first and then seeking certification (which has been a problem due to the insanely expensive audit process), but the EFF got the vendors on board first and then started doing the nuts and bolts.
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.
I don't see how this actually keeps the CA PKI from being a scam. While I personally trust the EFF & Mozilla right now, as long as I can't meaningfully revoke that trust, it's not really trust and the system is still broken.
You can revoke your trust in any CA at any time, you don't even need to see any errors! Just click the little padlock each time you visit a secure website and see if the CA is in your good books. If it's not, pretend the padlock isn't there!
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.
Yes you can. Obviously, you can choose not to make secure connections with sites certified by a CA you don't trust. But then you just can't use your bank's website anymore, or your search engine, or whatever.
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.
I'm curious as to whether Firefox's sync functionality propagates CA overrides across machines. If not then this is something you'd have to repeat over for every machine you use, making it effectively too tedious to be practical.
> 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 [0] 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[1]. 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.
This seems like a really great step toward an HTTPS web. It will be an immediately deployable solution that can hopefully TLS encryption normal and expected.
However, it doesn't do anything about the very serious problems with the CA system, which is fundamentally unsound because it requires trust and end users do not meaningfully have the authority to revoke that trust. And there's a bigger problem: if EFF's CA becomes the standard CA, there is now another single point of failure for a huge portion of the web. While I personally have a strong faith in the EFF, in the long term I shouldn't have to.
Agreed. For all the hoopla, this is basically just like any other CA (but free). Until we have a truly distributed (namecoin-esque) and accepted CA structure, signed certificates may as well be pipes directly to the NSA.
That said, not having to pay some jerk for sending me an email and having me enter a code is really nice. The current CA system is a pitiful excuse for identity verification, and not having to pay for it will be nice.
This certificate industry has been such a racket. It's not even tacit that there are two completely separate issues that certificates and encryption solve. They get conflated and non technical users rightly get confused about which thing is trying to solve a problem they aren't sure why they have.
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 hostmaster@digitalsushi.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.
The warning pages are really ridiculous. Why doesn't every HTTP page show a warning you have to click through?
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).
You're absolutely right. From first principles, HTTP should have a louder warning than self-signed HTTPS.
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.
Thanks for doing this. It's really great and its something that clearly needs to happen.
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.
We'll be in a position to deploy defenses like pinning (http://www.ietf.org/id/draft-ietf-websec-key-pinning-21.txt) for site operators who want more protection against the structural problems of the CA system. That will need to be implemented with care, but it should be possible.
Eventually maybe the browsers will do that. Currently far too many websites are HTTP-only to allow for that behavior, but if that changes and the vast majority of the web is over SSL it would make sense to start warning for HTTP connections. That would further reduce the practicality of SSL stripping attacks.
I totally agree that CAs are a racket. There's zero competition in that market and the gate-keepers (Microsoft, Mozilla, Apple, and Google) keep it that way (mostly Microsoft however).
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.
That's all good in theory, but there have been demonstrated attacks against man-in-the-middle-able protocols and we've lacked the ability to respond usefully, precisely because the protocols were designed to be man-in-the-middle-able. Everyone knows it's happening and it's even easier to detect than your example, but there's nothing useful to do with that knowledge other than complain.
> HTTP can be man-in-the-middled passively, and without detection; making dragnets super easy.
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).
> 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.
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.
It's slightly different. QUANTUM man-on-the-side deployments can always read packets and inject packets, but it appears cannot stop packets getting through or change them en route.
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>)
That's the standard motivation for CAs, but I don't buy it.
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.
The thing is, without a chain of trust, the self-signed certificate might be from you or it might be from the "snoops" themselves. Certificates that don't contain any identifying information are vulnerable to man-in-the-middle attacks.
This certificate industry has been such a racket. It's not even tacit that there are two completely separate issues that certificates and encryption solve. They get conflated and non technical users rightly get confused about which thing is trying to solve a problem they aren't sure why they have.
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.
I'm not entirely sure I understand your point, so if I misunderstood you please correct me.
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)
If you don't verify what is sent, I could easily send you a malicious web form. If you don't verify the key or cert behind the connection, anyone can claim to be x site.
Stopping snooping by encrypting without strictly checking certificates the first time you connect is better than not using encryption because it stops dragnet surveillance.
Also, active attacks (like MITM) are harder to do and easier to detect than passive attacks (snooping).
Nobody’s suggesting that self-signed certs be treated as trusted or CA-cert equivalent, only that they not be regarded as worse than unencrypted http. In the proposals being discussed, that attack would no more of a threat than MitMs currently are against http.
No, that does not make dragnet surveillance easier. Dragnet surveillance depends on not being easily detectible. However, a SSL MITM attack is easily detected, as it changes the fingerprint of the SSL-key of the site you're talking too. By recording fingerprints and comparing them over time or for different users, or directly contacting the site's operator (using a secure communication channel, e.g. meeting him in person), the existence of a MITM is easily proven.
BTW what you call "dragnet surveillance" is better described as "Pervasive Monitoring", see also RFC7258 "Pervasive Monitoring Is an Attack" [1].
> 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"
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.
> 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".
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. ...
They can get US corporations (including many CAs) to cooperate. For example, to obtain a fake (but perfectly working google.com certificate, they can ask Google (more or less) nicely to provide one, or they can go ask any CA instead. It's not likely that compromise is required with so many potential sources, some of which may be paid or coerced to cooperate.
PS. nice (presumably political) downvote further up ...
The NSA can do this, yes. But, any CA that issues a fake CA for Google will be found out rather quickly, and then will get blacklisted and lose business.
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.
This is precisely the problem with centralized security authorities. As we've seen a state actor can easily force a central authority to share it's private key, thereby granting the state actor the ability to untraceably create it's own certificate chains.
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.
Google is indeed in a (unique) good position to detect and possibly prevent a fake certificate, but we don't know if that's what they want or whether they can be coerced to cooperate. Millions of other websites are not protected in the same way.
That is completely ineffective if they get Google to cooperate and issue an update that pins the new cert - and due to how automatic updates work, the majority of users will be completely oblivious, and those who do notice the new certificate won't find it any more suspicious than any other certificate update.
Wouldn't help with google though - anybody who tried to fake a google cert would be caught by chrome within a few seconds. There is a lot of value associated with owning a browser. Enhanced security is just one of them.
You speak as if the power of NSLs has a functional limit - it doesn't, which is what makes the entire concept so dangerous.
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".
It's a letter, issued by an occult kangaroo court, that coup d'etat forces hold in hand while demanding the keys to the kingdom - a demand that can't be challenged in a legitimate court of law.
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.
An NSL can be used only to compel release of connection or transaction metadata, and cannot be used to compel disclosure of message contents. It's basically a fast-track for getting things like call records, and it most emphatically cannot be used to compel turning over a certificate or allowing a man-in-the-middle.
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.
Okay, so not an NSL. Incorrect terminology pointing at the same awful effect, an unaccountable court issuing unchallengeable rulings that cannot be discussed.
No substantial difference from the concept I'm complaining about.
How did you get Google into all this? If you're implying that Google owns a search site/Gmail/a browser, know that there are alternatives, which NSA's target could be using. A fake certificate from a trusted US CA can MITM any connection to almost any website from almost any browser.
Self-signed certificates are still better than http plain text. I understand not showing the padlock icon for self-signed certificates, I don't understand why you would warn people away from them when the worst case is that they are just as unsafe as when they use plain http. IMHO this browser behavior is completely nonsensical.
The warning is designed to let people know that who you're talking to can't be proven, which is important when someone tries to impersonate a bank, or your email provider, or any other number of important sites.
This is true for most sites now, but is being solved gradually, with hard-coded certificate pinning already shipping in Firefox and Chrome, and the HTTP Public Key Pinning extension coming soon.
Yes. That's not perfect. But it raises the bar for forgery to "can sign certificates as a root authority", which is still fairly high. (e.g. I can't do it, and neither can you.) It stops coffee shop/hotel wifi operators and mobile providers from injecting content into your session.
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.
How would a browser know that the the self-signed certificate that was just presented for www.mybank.com is intended to be self-signed (show no error, but also show no padlock) or whether it's the result of a MITM attack because www.mybank.com is supposed to present a properly signed certificate (show error)?
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 www.mybank.com, let the server redirect to https but don't show the lock icon if it's self-signed. This is no worse than an impostor that just doesn't redirect to https.
If the user typed https://www.mybank.com, show the usual warning for self-signed certificates.
But that don't protect you from a malicious user hijacking this domain in the next cubicle. Perhaps, if your switches are not properly configured , that the guy in the next cubicle ou do some arp spoofing and https://intranet.yourdomain would be served by a bogus server collecting passwords.
But your users won't notice the difference, because they are used to see the certificate warning on his browser.
The solution for this is to run your own CA internally and push out the cert to all the machines. (if you have byod stuff it makes it a little harder but you could still have an internal ca signing only a certain subdomain and get people ot install it)
How many people are careful to type "https" every time they visit a website? How many people pay close attention to the lock icon/color of the URL bar? This advice seems to ignore the existence of sslstrip [0] and related attacks, and the numerous countermeasures that have been designed to deal with this problem (e.g. HSTS).
How would a browser know that the fact that www.mybank.com doesn't use SSL at all is intended by the bank, or the result of a MITM attack? At the end of the day it all relies on the user seeing the (lack of) a padlock in his browser. So as long as you don't show a padlock (or a different kind of padlock) for www.mybank.com when the certificate is self signed, you're good.
No. Self-signed certificates are much worse because they bring a false sense of security.
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).
The extent to which this is true depends on browser behavior. With some browser behavior self-signed certs could make some users safer against some threats; with other browser behavior they could make some users more vulnerable to some threats.
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.
> With some browser behavior self-signed certs could make some users safer against some threats
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?
Well, the best example I know of is proposals to do opportunistic upgrades from HTTP to HTTPS, for example via a browser header in the HTTP reply. If the browser performs the opportunistic upgrade, and negotiates an HTTPS connection behind the scenes, and doesn't tell the user that the connection was served over HTTPS, then accepting a self-signed cert invisibly in this context makes the user no worse off than not performing the upgrade (and better off against an adversary who's not currently performing an active attack).
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).
Although such scheme is indeed safer than HTTP (protects against passive attacks), what you're describing is not self-signed certificates, but merely encryption (with new random _unathenticated_ keys per session).
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.
I agree that the certificates don't serve any useful function in this scenario; they might be required pro forma, but they aren't actually doing anything helpful.
> A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate.
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.
HTTPS with self-signed certificates remains better than plain HTTP. The fact that you can propose an unimplemented, unstandardized, theoretical scheme that would offer the same advantages as HTTPS with self-signed certificates does not make HTTPS with self-signed certificates worse than plain HTTP.
The use case for the CA system is to prevent conventional criminal activity -- not state-level spying or lawful intercept. The $200 is just a paper trail that links the website to either a purchase transaction or some sort of communication detail.
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.
Browsers shouldn't silently accept self-signed, but there is a class of servers where self-signed is the best we've got: connecting to embedded devices. If I want to talk to the new printer or fridge I got over the web, they have no way of establishing trust besides Tacking my first request to them.
But note that only works if the manufacturer can choose the name without an issue from the customer. For things like network appliances in larger companies that aren't going to want [generic number]manufacturer.com but want [my name].corp.[my company].com, you're stuck.
Yes, that's the status quo, and has been for a while. The point is that's currently the best you can do. For boxes without external exposure, this work won't change anything, but a standardized protocol for dealing with boxes with external exposure would still help some use cases.
True, but on many small networks, you aren't addressing the embedded device by a FQDN.
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.
FQDN doesn't have to mean publicly accessible. I have a personal subdomain that points to an internal IP. It's kinda weird to do with IPv4, but it works fine, and with IPv6 it'll be natural, since each device will probably have a globally unique address anyway, even if it can't be accessed outside of your LAN.
Why should my fridge have a FQD name? What purpose does that serve?
To allow you to create a signed certificate to authenticate it?
Why install a firewall in each device if you can install one on the router that works for everything?
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.
I bought a camera the other day with the nifty feature of having an NFC tag embedded in it to guide your phone to launching (and installing, if necessary) the companion mobile app.
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.
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.
> The solution is absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn't quite come up with.
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:
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.
>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.
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.
"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."
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).
> Tell me how the logic works here (for an average user).
"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.
If someone forwards plaintext, it's called a proxy.
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.
To know something is insecure can be acceptable. To think something is secure when it isn't can be far more dangerous. I'm considering secure to mean encrypted and identity reasonably verified. Whatever your thoughts on the CA process it serves a purpose.
There are plenty of other things to complain about. EV for one.
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.
What does it matter who issues your cert if your registrar controls your domain name? They can transfer your domain name to the FBI, your competitor, your ex-husband, whoever. They can keep it for themselves, and they can publish their own DNS servers as authoritative, making all traffic flow through them anyways. They already are in 100% control of your domain and you are at their mercy. You already trust them enough to buy the domain from them. Why would you want to give a third party that same level of access when you don't have to? The CA's would have you believe that they have tighter security than anyone else, so you should trust them. That's silly. Your registrar has more control over your domain than your CA, so either their security has to be just as good, or you are screwed anyways.
This article[0] is largely about DNSSEC and DANE but it might give you some insights why making registrars the sole authorities isn't such a good idea.
I may be dense but it seems to me that your registrar is still the trusted entity no matter what:
- 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 joe@fbi.gov 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.
> This case should be eliminated. We need to stop publishing stuff over HTTP. Period.
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.
No it is not. I have talked about this on here before, but I don't mind repeating myself:
- 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.
The authentication provided by the extant PKI system is much weaker than the encryption provided. Any CA can do anything it wants, and browsers trust lots of them.
There's also significant overhead to the community at large in having both HTTP and HTTPS be reasonable systems to use, and requiring that HTTP not show loud warnings. There's also a risk to your organization that you're teaching users that some HTTP sites are reasonable, which is a hard judgment for them to make. I can put up an external website which claims to be internal, and probably get some passwords or confidential information that way.
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.
The registrar issuing cert solution would certainly speed up HTTPS adoption; you're dealing with one less org to secure your site. The down-side is that if you decide to move registrars, that still complicates things. What if the new registrar refuses to issue a new cert without a hefty fee? Or what about revoking the previous cert? Now the registrar is functioning as a de facto CA so it doesn't completely eliminate the middle-man factor.
I'm hoping the EFF project will smooth over these hiccups, which is why I'm looking forward to it.
> The down-side is that if you decide to move registrars, that still complicates things. What if the new registrar refuses to issue a new cert without a hefty fee?
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.
If the popularity of GoDaddy has taught me anything, it's that people use what they know; not what's good. The list of companies that should have gone out of business is as long as the number of years since commerce began.
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).
There's no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it's trusted, it can sign off on a cert for www.google.com.
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.
Interesting - that's news to me, and does allow a domain-registry-based hierarchy. I guess there's the old revocation-check problem, though - when someone transfers a domain or it expires, you'd need to be able to revoke the authority cert. Potentially leads to a lot of revocation checks to validate a cert chain correctly...
You mention that the revocation-check problem is old, which is certainly true, but I think you allude to the possibility that a domain-registry-based hierarchy will exacerbate that problem in the form of an increase in revocation checks. I'm not sure that would be the case; it should be about the same. What difference does it make if I owned a domain, got a cert from a CA, and stopped owning the domain -- vs -- got that cert from my registrar? If anything this helps the process, because my registrar knows when I stop owning the domain whereas a CA has no clue and relies on the cert's expiration date exclusively.
I guess you're right - I was considering the fact that someone once owned a domain was a threat, but it is already.
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.
I think this is kind of backwards? I.e. a CA that implements name constraints for one of its sub-CAs does limit the certs that sub-CA may sign. However, name constraints do not allow one to say "for this domain, only this sub-CA may sign certs", which is more what I feel we're looking for here?
> There's no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it's trusted, it can sign off on a cert for www.google.com.
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.
> 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.
The problem here is that getting a vetted cert - or worse, compromising the authority that vets those certs is relatively trivial for a nation state, or even someone that's morally compromised enough to say, kidnap the CA Director's family. The fact is, trust is easily compromised and the current infrastructure needs to be hardened against that.
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?
> 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.
>We need to stop publishing stuff over HTTP. Period.
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.
FWIW, this is the route we are already going with HTTP/2: as implemented SPDY pretty much requires encryption.
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.
I understand your argument. Barring some of the hyperbole of your worst case scenario, I totally get it.
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.
I am not quite sure what you are saying. Is it that it is in fact better to allow HTTP to exist vs providing HTTPS backed by some type of trusted infrastructure? Or is it that you are saying that we can build a brand new from scratch solution and need to fix the existing system somehow?
It's definitely an antipattern. It's hard to solve until we get HTTPS deployable everywhere, because the first browser to defect from this antipattern will lose all its users, so it's extremely important to push on HTTPS being deployable and deployed everywhere.
Authentication and encryption are fundamentally separate ideas, and the problem here is that the CA system mixes them together, when an optimal solution (read: encryption everywhere) would be to tackle them separately.
Encrypted (Certified) AUTHENTICATED & ENCRYPTED
Encrypted (Self-Signed) NOT AUTHENTICATED & ENCRYPTED
Unencrypted NOT AUTHENTICATED & NOT ENCRYPTED
Doing financial work or communicating with friends/coworkers? Make sure you're connection is authenticated and 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.
There's no question in my mind that the whole thing is a racket and militates against security (you generally don't even know all the evil organisations that your browser implicitly trusts - and all the organisations that they trust etc).
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.
The SSH approach is exactly what I was thinking of, where you know the fingerprint of the other side you're connecting to.
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.
With SSH you usually own both endpoints (or at least trusting your cloud provider).
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.
You'd need a strong root key and subkeys that rotate underneath. To change the root key would require signing by the original root and a new message to appear for confirmation.
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.
No, the question is what to do when you need to rotate them. Because that need will arise somewhere, globally, if we were to run the secure web on trust-on-first-use.
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.)
Private to the NSA and reasonably private to the person sitting next to you are different use cases. The current model is "I'm sorry, we can't make this secure against the NSA and professional burglars so we're going to make it difficult to be reasonably private to others on the network".
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.
The person next to you in cafe can MITM a self-signed TLS connection just as easily as the NSA; and the NSA can probably MITM a CA-signed TLS session, since the U.S. government owns or has access to quite a few root certificates. So, "no self-signed certs" is really a measure to protect you from the lowest level of threat. Almost any attacker than can MITM http can MITM https with self-signed certs that you never verify in any way. Encryption without authentication is useless in communications.
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.
+1 for Certificate Patrol; used to use it until it got too annoying for me. Same with RequestPolicy; another great extension that is unfortunately a lot of work if you surf a lot, esp these days, when everything is hosting assets on CDNs.
I used to use EFF's SSL Observatory until I realized it spits out lots of extra http requests. X509 is inherently flawed/complex and adding a browser plugin to make it better feels wrong.
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.
Quite the contrary: SSH's system means that you only have to "do your homework" when first connecting to the server. It seems I have 64 lines in my ~/.ssh/known_hosts (there are probably quite a few duplicates, because this seems high to me) and almost never have SSH tell me the key has changed and someone could be doing something nasty. When it does, I almost always know why, and when I don't then I try to contact the admin before connecting.
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.
My browser also offers me to accept any self-signed certificate, I can investigate it and then I can accept it and it won't ever bother me again, until the certificate changes.
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.
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.
> 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".
Well... that's true regardless, as the NSA almost certainly has control over one or more certificate authorities.
Moxie Marlinspike's Perspectives addon for Firefox was a good attempt to resolve some of the problems with self-signed certs.
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.
Here's one thing that's NOT the solution: throwing out all encryption entirely. Secure vs insecurse is a gradient. The information that you're now talking to the same entity as you were when you first viewed the site is valuable. For example it means that you can be sure that you're talking to the real site when you log in to it on a public wifi, provided you have visited that site before. In fact, I trust a site that's still the same entity as when I first visited it a whole lot more than a site with a new certificate signed by some random CA. In practice the security added by CAs is negligible, so it makes no sense to disable/enable encryption based on that.
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)
It's interesting that your boogeyman in the NSA and not scammers. I think scammers are 1000X more likely. Escpecially since the NSA can just see the decrypted traffic from behind the firewall. There's no technology solution for voluntarily leaving the backdoor open.
The solution, at least for something decentralized, seems to be a web of trust established by multiple other identities signing your public key with some assumption of assurance that they have a reasonable belief that your actual identity is in fact represented by that public key.
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?
I'm pissed off 'cos I'm on the board for rationalwiki.org and we have to pay a friggin' fortune to get the shiny green address bar ... because end users actually care, even as we know precisely what snake oil the whole SSL racket is. Gah.
Here's some comparison screenshots of the "bling" that is being described (hard to even tell that some of these sites are SSL'd without getting the EV)
It's not enough to keep the snoops out - you need to KNOW you're keeping the snoops out. That's what SSL helps with. A certificate is just a key issued by a public (aka trusted) authority. Sites can also choose to verify the certificate: if this is done, even if a 3rd party can procure a fake cert, if they don't have the same cert the web server uses, they can't snoop the traffic.
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).
Perhaps you should understand a system before slandering it? As others have said, encryption without authentication is useless.
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.
That's the third comment of yours in which I've seen you taunt downvoters via edits in this thread alone. That's why I'm downvoting you. Knock it off, please.
I'm sorry it came across as a taunt, I didn't mean it like that.
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".
They might as well say something even more ominous: "If your certificate expires, your site will no longer be accessible."
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).
Without some kind of authentication, the encryption TLS offers provides no meaningful security. It might as well be an elaborate compression scheme. The only "security" derived from unauthenticated TLS presumes that attackers can't see the first few packets of a session. But of course, real attackers trivially see all the the traffic for a session, because they snare attackers with routing, DNS, and layer 2 redirection.
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!
>The only "security" derived from unauthenticated TLS presumes that attackers can't see the first few packets of a session
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.
Do you think that with public key pinning self-signed certs begin to make sense? Also, do you feel that CAs and the PKI system do provide appropriate authentication (this being a cost-benefit rather than a 100%-correctness analysis)?
Yes! Key continuity is a legitimate identity scheme; the only trick is to implement it scalably, so it actually happens, rather than being a fig leaf (an unworkable variant of key continuity already exists in browsers today).
I think the CA system by itself is inadequate, but unlike unauthenticated TLS, actually does provide some security.
Then I don't see how that would be true. Mimicking a server requires significantly more effort that simply storing the traffic. So even if someone were able, it doesn't follow that they would want to go through that effort in every case.
Wildcard SSL certs are ~$100/year. Those have always been much more of a racket, but they're so worth the extra cost to set them up once on your load balancers and not have to think about SSL certs again for 5+ years.
I'm all for CAs to burn in a special hell. The other cost, though, was always getting a unique IP. Is that still a thing? Has someone figured out multiple certificates for different domains on the same IP? Weren't we running out of IPv4 at some point?
Wasn't WOT (Web Of Trust) supposed to fix this? Basically, I get other people to sign my public key asserting that it's actually me and not someone else, and if enough people do that it's considered "trusted", but in a decentralized fashion that's not tied to "authorities"?
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.
1. I really hope this is hosted in a non-FVEY territory.
2. Why can't we set a date (say, 5 years?) when all browsers default to https, or some other encrypted protocol, and force you to type "http://" to access old, unencrypted servers?
There's a scenario (simplified for illustration, but entirely possible) that's normally not a huge risk because there are many CAs, and they are private, for-profit companies that have an economic incentive to protect you and your certificate's ability to assure end users that a conversation's privacy won't be compromised.
1) browser requests site via SSL
2) MITM says, "let's chat - here's my cert"
3) browser asks, "is this cert legit for this domain?"
4) MITM says, "yes, CA gave us this, because of FISA, to give to you as proof"
5) browser says, "ok, let's chat"
I'm not trying to spread FUD, but if you're NSA and you've been asking CAs for their master keys for years, doesn't a single CA sound great (free and easy == market consolidation), and doesn't EFF seem like the perfect vector for a Trojan horse like this, given its popularity and trust among hacker types gained in recent years?
I'm not sure I follow that line of reasoning. Each CA is independently and completely able to issue certificates (not counting EV, but let's leave that out). There are hundreds of CAs. Depending on your trust store, some of them are literally owned by the US Department of Defense. Others are owned by the Chinese government.
How does having _fewer_ CAs make anything easier? Why is the EFF a better route than any of the various other companies that have gotten themselves in the CA program? And given that all the CAs are equivalently trusted at a technical level, why does the human trust afforded the EFF affect whether it's a better target?
We will look for ways to mitigate the risk of misissuing for any reason, including because someone tries to coerce us to misissue. One approach to this that's interesting is Certificate Transparency.
There's also HPKP, TACK, and DANE, plus the prospect of having more distributed cert scans producing databases of all the publicly visible certs that people are encountering on the web.
Let's Encrypt is going to publish records of everything it signs, either with Certificate Transparency or some other mechanism.
Browsers will be able to check any cert signed by the Let's Encrypt CA against the published list. If there's a discrepancy, that will be immediately detectable.
Out of curiosity, what if MITM says, "include me in this list for IP <user IP>"? If the check is not done in a way that solves the byzantine generals problem, I don't see how this feature provides any more protection, other than one more hoop to jump through.
Certificate Transparency tries to solve the Byzantine Generals problem (up to high levels of collusion). Take a peek at their design -- it's pretty interesting!
It does rely on the legitimate site owner actively checking the records to notice the misissuance. Maybe that process could be automated somehow.
If you can corrupt both the authority signing the certificate and the authority signing the Certificate Transparency append-only log, you can successfully MITM a connection.
However, if the client is ever subsequently on a non-MITMed connection, it can detect the certificate disappearing from the append-only log - and the signed certificate and signed append-only log constitute irrefutable evidence that the two authorities were compromised.
As all legitimately issued certificates are in the Certificate Transparency logs, browser vendors can grandfather them in so they keep working after they drop the CA certificate from the trust root. This kills the CA.
This would give CAs the power to refuse requests from the NSA, because their hands are tied - no matter what coercion the NSA threatens, the CA can't issue an MITM certificate without getting shut down.
Obviously it remains to be seen whether this will work in practice.
This is not an attempt to reduce the CA system to a single CA. The intent here is to provide a simple and free way for anyone to get basic DV certs. If we can also contribute to CA best practices, and help improve the CA system in general, we'd like to do that too.
Let's Encrypt is only planning to issue DV certificates, since that is the only type that can be issued in a fully automated way. Many organizations will want something other than DV, and they'll have to get such certs from other CAs.
Also, our software and protocols are open so that other CAs can make use of them.
The NSA (or any other agency) only has to coerce any single CA to cooperate. As long as it's in the standard set shipped with browsers, its certificates are accepted.
And pretty much every major government directly or indirectly controls one or multiple CAs that are in the standard set.
Won't people need to have LetsEncrypt CA certificate installed on their computers to not get that red SSL incorrect certificate thing? Other than that, this is awesome.
Thanks for the clarification! You might want to add that point to your technical how-it-works section[1]. I was wondering how older browsers would accept a new CA's signature.
Also, I really wish AOL would have donated their root certs to y'all[2] so you didn't have to set up a whole new CA.
I don't know why AOL keeps being brought up, but it's highly unlikely they would do this. For one, it's probably used internally for smart cards/SMIME. Secondly, it'd be very hard to get AOL to spend money on doing something for free. Moving a CA to a different company is no small feat, operationally...
or e-mail me about them. So far this has only been tested on a handful of configurations and will clearly need to be tested on many more over the next few months.
Please be careful when running it on your live server: if it does manage to get a cert right now, that cert won't be accepted by clients and will produce cert warnings (and if you use the "Secure" option at the end, you'll also be generating redirects from the HTTP site to the cert-warning-generating HTTPS version).
This is great news, but I am wondering how they will handle revoking certificates. For example: Do we really want malware sites popping up with valid Ssl certificates?
We have DNS system in place which should be enough to establish trust between browser and SSL public key. E.g. site could store self-signed certificate fingerprint in the DNS record and browser should be fine with that. If DNS system is spoofed, user will be in bad place anyway so DNS system must be secured in any case.
various 3rd parties. this is required by the cab forum which my browser requires as well.
inform yourself if you want to write stuff like that.
even more, its sad that people think CAs have zero checking and just give what, money to browsers to be included? Thanksfully its not like that yet.
Who's auditing the auditors? Remember Moody's? It's not entirely analogous, but it's not far from it.
At some point down the chain, you have to rely on trust to some degree. Either disappear in to the wilderness and completely disconnect from the grid or - at some point - you have to trust someone.
One possible solution is a BitCoin-like block chain of certificate proof, so that a website's certificate can be verified against the domain without a central authority.
What authorization is required in this scenario? I'm talking about a novel idea here, one that doesn't fit into the existing CA model. There would be no CA in this scenario; verification would be decentralized, based on shared information, not on knowledge of a secret.
And we should do this, because this Let's Encrypt CA, while a great step forward, is still vulnerable to man-in-the-middle attacks, explained in this video:
I'm so excited for this. I know both the people working on the team from the University of Michigan, and both are extremely smart people passionate about web encryption.
While this is nice and I'm happy to see such a product coming, I still don't see a free TLS solution for my smaller projects. Heroku will still charge me $20/mo for TLS even if I have my certificate. Cloudflare will also want to charge me to inspect TLS. I could drop both and get a Linode but then that costs too and is a pain to setup a server myself.
ACME sounds great. Copying codes from emails is suboptimal at best. Free certificate from command line and free revocation from the same client sound even better.
I just don't know about the automatic configuration tool. Like webpanels for managing a server, it has never worked for me.
475 comments
[ 2.6 ms ] story [ 248 ms ] threadLike StartCom selling Class 2/3, running a CA is very expensive and I wonder how they plan on recouping the fees for this.
Is it? Seems like it should be dirt cheap to me. It's basically just an API for generating and revoking certs.
You also have to pay for your own cage in a datacenter, the HSM, validation staff, etc...
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 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 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.
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.
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.
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 [1] 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 [2] (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 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
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).
https://en.wikipedia.org/wiki/DigiNotar#Refusal_to_publish_r... https://blogs.comodo.com/uncategorized/the-recent-ra-comprom...
https://www.globalsign.com/certificate-authority-root-signin...
There are a few other vendors that I've seen offer similar services.
Apache only or also Nginx?
Who is the CA?
No way I am running something like this on a production machine.
I like the idea but I would rather have the client just output the certificate and key in a dir so I can put the files where I need them and I can configure the changes to my webserver.
Also this does not solve the issue of a CA issuing certificates for your domain and doing MITM.
Our Apache code is a developer preview, we'll be working on Nginx next.
ISRG will be operating a new root CA for this project. Although if you think that your choice of CA makes you more or less secure, you may not have understood how PKIX works -- you can buy a cert from whichever CA you like, but your adversary can always pick the weakest one to try to impersonate you.
Are you going to be cross-signed by IdenTrust or something? If you're really going to try and create a new root CA from scratch, surely you will be impaled on the spike of low coverage for many years?
Does that mean every client/browser will need to be updated to include the new CA? Or will it somehow be signed by other (competing) CAs?
I like the idea of this project, and I think it's a great thing for the Internet - I just worry that it will take a long time for it to be usable in practice.
https://github.com/letsencrypt/lets-encrypt-preview
> I would rather have the client just output the certificate and key in a dir
Could not agree more.
[1] https://letsencrypt.org/howitworks/
I run plenty of tools right now on production boxes that I personally haven't fully audited—we all do. This tool should be simple and widely used enough that it will be trustworthy.
For the cautious, it would be nice if the tool offered a mode that could be run as a normal user, even on a different machine. It'd have to be an interactive process:
1. "Enter domain to be signed." 2. "To validate ownership of the domain, create a TXT record on xxx.example.domain with 'na8sdnajsdnfkasdkey' as the value." 3. "Domain ownership has been validated. Please paste the CSR." 4. "The zone has been signed. Here is your certificate:"
Much less convenient (basically the same as the process with current CAs), but it would allow security-conscious admins to use the CA in a way that is comfortable for them. Since the tool is open source, it should be fairly easy for someone to write their own tool that speaks to the CA while providing this interactive process.
The tool is interesting and to be honest, I'll be comfortable using it (I'm not running anything high-profile or sensitive). However, the real news here is the new CA—the tool is merely a convenience.
They are creating a new CA for this purpose.
I can't imagine this will replace the manual learn-pay-experiment-error-success process we have at the moment, so experts will still be able to control the process manually.
It doesn't address CA MITM attacks but it does significantly reduce non-CA MITM attacks by remove the two primary objections to deploying SSL: cost and complexity. Bravo EFF - this could be the most significant step in SSL adoption ever.
If you're comfortable editing your own Apache configs, then you'll only need to use the client to obtain the cert and not to manage its installation long-term. (The client does need to reconfigure the web server while obtaining the cert as part of the CA validation process.)
The protocol is openly published, so you can write your own client too, or follow the protocol steps manually -- or any web server developer or hosting platform can develop their own alternative client.
There does need to be some client to speak the protocol, but there's no attempt to force you to use it to manage your certs and configs if that's not what you want. The convenience is aimed at people who don't understand how to install a cert, or who think that process is too time-consuming.
Is there any reason why I would want to use https for this use case?
Or what does "entire web" mean?
HTTPS will also make an attacker unable to change your content.
Over http it could conceivably have malicious or tracking content introduced without your knowledge.
If you use HTTPS you prevent alterations to that traffic and people receive exactly what you expect they should receive.
Examples of recent ISP misbehaving on non-https websites just 25 days ago on HN: https://news.ycombinator.com/item?id=8500131
Note that the Verizon issue isn't anything entirely content altering but someone who lives in a country with strict monitoring of traffic could easily change the wording of your website to match their propaganda if you aren't using HTTPS.
So yes, your content is publicly available free stuff and no one is probably sending you user login credentials or credit cards but it still matters.
Yes it can help you stop:
ISPs inserting adverts into your content (this has happened)
Governments censoring your content or rewriting it
Governments putting people in jail for reading your publicly available (in your country) content, which is illegal in theirs
People impersonating your website
But if you don't want to use it, that's cool too. I suspect all websites will be encrypted at some point soon though, the disadvantages are getting less and less important.
How does that work, surely the gov can still see people accessing the information by monitoring network traffic and the info itself is still public. HTTPS doesn't encrypt the actual request traffic does it, and in any case the gov would still see which server the traffic is going to unless you're using something like tor [and possibly still then].
"User X browses Wikipedia"
and
"User X browses Wikipedia articles about topics A, B, C"
where topics A, B, C could be anything user X doesn't want people recording them reading about: for instance, various political articles, articles about mental illness, articles about LGBT issues, etc. Fill in the blanks.
One interesting idea I heard from someone recently is tuning compression so that you target a small number of total page sizes -- rather than padding to expand pages to the same sizes, just don't compress them all quite as well as you could have.
Both GnuTLS[1] and Nginx[2] have length hiding implemented. But AFAIK OpenSSL doesn't have it yet, so most users are still left in the dark.
[1]http://www.manpagez.com/info/gnutls/gnutls-3.2.10/gnutls_180...
[2]http://nulab-inc.com/blog/nulab/securing-nginx/
It might still be challenging to get large sides to adopt padding that will increase the amount of traffic they send (of course, the idea of reducing the efficiency of compression has the same net effect). But it's great to know that there's already a tool in place for traffic padding, at least in some implementations.
However, you can figure out what pages on a large public site like Wikipedia people are reading over HTTPS, based on statistical traffic analysis, because you can see the size of the request, page, and each of the images. Combined with link following analysis, you can make a fairly accurate guess as to what people are reading.
Like you, I don't host any private or remotely sensitive information. I'm encrypting my site because I think it's the right thing to do, even though there's little personal return on investment.
Looks neat.
If I'm running a single web app on a single Ubuntu server using Apache then I'm set! If I'm running multiple web apps across multiple servers using a load balancer, nginx on FreeBSD then...
All the same I'm really looking forward to this coming out, it can be nothing but good that all of these companies are backing this new solution and I'm sure it'll expand and handle these issues as long as a good team is behind it.
That's a bit more then "giving us a cert"
If you want, the client can just give you the cert at the end instead of installing it. In the common case for a user who's not currently comfortable with the process, the client is automating several things -- generating a private key and CSR, proving control of the domain, and installing the key and cert in the server.
My dream cli tool would just generate key, get certs, and dump them in the dir of my choice. The server config is nice to have but not really essential or the hard part.
Really looking forward to seeing this happen, is there any beta program at present?
Generate key, Generate CSR, Send CSR, Receive Certs from CA, Verify ownership, Install certs
Presumably their command line client creates the key, the CSR, sends the CSR, then gets back the certs (at least I'd hope so). I'd be happy to use a vetted command line utility which did that, or even just parts of that process, if I were sure the private key were not transmitted. It's just automating stuff which with current CAs needs to be done manually.
Domain validation is done through a challenge (issued by a CA) to sign arbitrary data and put on a URL (covered by the domain) the CA can then query. This seems pretty solid. Better then email.
I think it's about time for a free CA that is recognized by all clients, but you still need to establish a trust chain to exchange a CSR for a signed certificate. This service needs to be server agnostic. The barrier to adoption isn't configuration, and HTTPS isn't the only thing that uses certificates.
Because of the open protocol we also aspire to support users with more complex configurations and requirements, who are absolutely welcome and encouraged to write their own implementations of the protocol and integrate with their own existing certificate management and configuration methods. If you think of other barriers to adoption that we can help with, please let us know and we'll try to address them; if you just want our certs for free, please get them and enjoy!
I do want your certs for free! But I also want/need to trust you and know that you're following best practices, not just with me but with everyone.
You can tell because our software is open source, written in Python.
https://github.com/letsencrypt/lets-encrypt-preview
We expect the users to get this software from their operating system repos, like from the Debian package repository -- the very same place they get their Apache or Nginx packages. We are not asking people to get the software directly from us, or to use it without being able to read it and check that it's safe and does what they want.
Edit: And if you want to implement your own client, we encourage you to do that -- the more clients the merrier!
We'll be doing quite a bit of work based on user feedback between now and when we go live. We're well aware that we need to cater to a variety of types of users.
We've been working with CloudFlare to drive HTTPS adoption, and plan to work with them further on integration.
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=583935
But syncing which certificates to delete is probably a much harder sell.
At least there's a way to do programmatically:
Unfortunately, it couldn't on Chrome, because you can't even access a page's certificate from an extension in Chrome:
http://stackoverflow.com/questions/18689724/get-fingerprint-...
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 [0] worked?
[0] http://convergence.io/
https://developer.mozilla.org/en-US/Add-ons/Overlay_Extensio...
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[1]. 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.
1. https://code.google.com/p/chromium/issues/detail?id=93636
Incidentally, I can also add my own CA.
However, it doesn't do anything about the very serious problems with the CA system, which is fundamentally unsound because it requires trust and end users do not meaningfully have the authority to revoke that trust. And there's a bigger problem: if EFF's CA becomes the standard CA, there is now another single point of failure for a huge portion of the web. While I personally have a strong faith in the EFF, in the long term I shouldn't have to.
That said, not having to pay some jerk for sending me an email and having me enter a code is really nice. The current CA system is a pitiful excuse for identity verification, and not having to pay for it will be nice.
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 hostmaster@digitalsushi.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.
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.
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.
https://www.eff.org/deeplinks/2014/11/starttls-downgrade-att...
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.
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.
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" [1].
[1] http://tools.ietf.org/html/rfc7258
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.
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. ...
PS. nice (presumably political) downvote further up ...
(for the record, I didn't downvote you)
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.
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.
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 :(
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.
[0] http://convergence.io
I'm really having trouble figuring out the attack scenario unique to self-signed certificates that you don't have with plain http.
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.
[0] http://www.thoughtcrime.org/software/sslstrip/
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:
http://www.tcpcrypt.org/
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 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.
http://www.reddit.com/r/ProgrammerHumor/comments/2l7ufn/alwa...
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.
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 not?
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?
Why install a firewall in each device if you can install one on the router that works for everything?
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.
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.
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".
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:
https://github.com/okTurtles/dnschain
If you're in San Francisco, come to the SF Bitcoin Meetup, I'll be speaking on this topic tonight:
http://www.meetup.com/San-Francisco-Bitcoin-Social/events/18...
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.
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.
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.
( http://wingolog.org/archives/2014/10/17/ffs-ssl )
...it should probably look like this:
Safe against active attacks:
Safe against passive attacks: Safe against world peace, ie. UNSAFE:"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.
There are plenty of other things to complain about. EV for one.
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.
As long as you can transfer the domain out I guess it's not too bad.
[0] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...
- 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 joe@fbi.gov 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.
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).
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.
[1] http://blog.codekills.net/2012/04/08/adventures-in-x509-the-... [2] http://middleware.internet2.edu/pki06/proceedings/chadwick-n...
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.
> 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.
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.
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.
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.)
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.
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.
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.
Well... that's true regardless, as the NSA almost certainly has control over one or more certificate authorities.
But I agree with the sentiment. :)
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.
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)
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?
https://www.expeditedssl.com/pages/visual-security-browser-s...
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).
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...
"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).
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.
https://en.wikipedia.org/wiki/SubjectAltName https://en.wikipedia.org/wiki/Server_Name_Indication
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.
1. I really hope this is hosted in a non-FVEY territory.
2. Why can't we set a date (say, 5 years?) when all browsers default to https, or some other encrypted protocol, and force you to type "http://" to access old, unencrypted servers?
There's a scenario (simplified for illustration, but entirely possible) that's normally not a huge risk because there are many CAs, and they are private, for-profit companies that have an economic incentive to protect you and your certificate's ability to assure end users that a conversation's privacy won't be compromised.
1) browser requests site via SSL
2) MITM says, "let's chat - here's my cert"
3) browser asks, "is this cert legit for this domain?"
4) MITM says, "yes, CA gave us this, because of FISA, to give to you as proof"
5) browser says, "ok, let's chat"
I'm not trying to spread FUD, but if you're NSA and you've been asking CAs for their master keys for years, doesn't a single CA sound great (free and easy == market consolidation), and doesn't EFF seem like the perfect vector for a Trojan horse like this, given its popularity and trust among hacker types gained in recent years?
How does having _fewer_ CAs make anything easier? Why is the EFF a better route than any of the various other companies that have gotten themselves in the CA program? And given that all the CAs are equivalently trusted at a technical level, why does the human trust afforded the EFF affect whether it's a better target?
http://www.certificate-transparency.org/
There's also HPKP, TACK, and DANE, plus the prospect of having more distributed cert scans producing databases of all the publicly visible certs that people are encountering on the web.
Only one "root CA" to trust per TLD, and it's free if you own a TLD that supports DNSSEC (most do these days).
Now we just need the DANE check built into the browser without any plugins that require installation.
Browsers will be able to check any cert signed by the Let's Encrypt CA against the published list. If there's a discrepancy, that will be immediately detectable.
It does rely on the legitimate site owner actively checking the records to notice the misissuance. Maybe that process could be automated somehow.
However, if the client is ever subsequently on a non-MITMed connection, it can detect the certificate disappearing from the append-only log - and the signed certificate and signed append-only log constitute irrefutable evidence that the two authorities were compromised.
As all legitimately issued certificates are in the Certificate Transparency logs, browser vendors can grandfather them in so they keep working after they drop the CA certificate from the trust root. This kills the CA.
This would give CAs the power to refuse requests from the NSA, because their hands are tied - no matter what coercion the NSA threatens, the CA can't issue an MITM certificate without getting shut down.
Obviously it remains to be seen whether this will work in practice.
Let's Encrypt is only planning to issue DV certificates, since that is the only type that can be issued in a fully automated way. Many organizations will want something other than DV, and they'll have to get such certs from other CAs.
Also, our software and protocols are open so that other CAs can make use of them.
And pretty much every major government directly or indirectly controls one or multiple CAs that are in the standard set.
- Obtain a browser-trusted certificate and set it up on your web serve
IdenTrust is listed as a sponsor and is the CA for the letsencrypt.org certificate so I'm guessing they're doing some sort of partnership.
Also, I really wish AOL would have donated their root certs to y'all[2] so you didn't have to set up a whole new CA.
[1]: https://letsencrypt.org/howitworks/technology/
[2]: https://moderncrypto.org/mail-archive/messaging/2014/000618....
https://github.com/letsencrypt/lets-encrypt-preview/issues
or e-mail me about them. So far this has only been tested on a handful of configurations and will clearly need to be tested on many more over the next few months.
Please be careful when running it on your live server: if it does manage to get a cert right now, that cert won't be accepted by clients and will produce cert warnings (and if you use the "Secure" option at the end, you'll also be generating redirects from the HTTP site to the cert-warning-generating HTTPS version).
The certificate isn't saying "this website won't infect your computer", it's saying "you're talking to the real owner of this domain".
What you're talking about is being introduced alongside DNSSEC, and it's called DANE.
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
inform yourself if you want to write stuff like that. even more, its sad that people think CAs have zero checking and just give what, money to browsers to be included? Thanksfully its not like that yet.
At some point down the chain, you have to rely on trust to some degree. Either disappear in to the wilderness and completely disconnect from the grid or - at some point - you have to trust someone.
https://cabforum.org/baseline-requirements/ https://www.mozilla.org/en-US/about/governance/policies/secu... https://www.mozilla.org/en-US/about/governance/policies/secu...
Geez the people without a clue wanting to patronize on HN - I'm telling you - nothing like that to lose faith in humanity.
We can all look at the variety of web-of-trust methods to see how well that's taken off amongst internet users.
https://github.com/okTurtles/dnschain
You can replace all CAs with a single blockchain.
And we should do this, because this Let's Encrypt CA, while a great step forward, is still vulnerable to man-in-the-middle attacks, explained in this video:
https://vimeo.com/100433057
I just don't know about the automatic configuration tool. Like webpanels for managing a server, it has never worked for me.
Sorry agwa.