Why do we have to go through this whole SSL certificates thing and can't just have a simple, automatically secure, I-do-nothing-and-my-website-is-secure protocol?
Seriously though. If secure is the default from now on, why can't it actually be the default?
Ok I'm new to this and I know it's still beta, but it seems:
1. Still WAY too complicated (look at all the stuff you have to know and type)
2. Doesn't seem to support my preferred OS (Windows) or web server (IIS) what-so-ever. Which is strange since, from my experience, installing certs in IIS is already far easier than in Apache and Nginx. (Although maybe that's why they perceive it as less of a priority?)
We've had hundreds of people remark that they found Let's Encrypt faster and easier to use than other CA offerings (though most of those people were using Apache on Debian-based systems), so I think we are getting somewhere. But we definitely hope that upstream web server projects and hosting environments will integrate ACME clients of their own, like Caddy has done, so that eventually most people won't need to run an external client at all and won't have to worry about compatibility or integration problems.
> 1. Still WAY too complicated (look at all the stuff you have to know and type)
The website mentions at the bottom that they're intending to get all of this automated, but they're not at that point yet; they're still in public beta. Certainly all those commands look automatable, just with enough integration with lots of distros / web servers, testing, and debugging. The Let's Encrypt protocol (ACME) is very much designed so that a web server can acquire a certificate with just about no human interaction besides telling it to do so, and keep it up-to-date with no human interaction.
I certainly agree that the instructions on that website are still way too complicated for general use, though far, far simpler than the status quo ante Let's Encrypt.
> 1. Still WAY too complicated (look at all the stuff you have to know and type)
I didn't realise that people getting SSL certs and administrating servers don't know how to read a literally one-page rundown of what to run. They also have helper scripts to make it much simpler.
> Which is strange since, from my experience, installing certs in IIS is already far easier than in Apache and Nginx. (Although maybe that's why they perceive it as less of a priority?)
nginx literally takes less than 10 minutes to set up not only SSL, but also CSP and several other very important security features.
Do you actually own hundreds of personal websites? (And you could still desync them, anyway.) Or is this a use case where wildcards would be useful. I sort of disagree with LE's decision to not care about wildcards for now, though I understand that it's simpler, at least while it's in beta.
That's per IP, you're also limited to 5 requests per domain name per week. In my case, I have a bunch of subdomains for various stuff that all counts against the limit for the main website. I suppose I ought to combine the CSRs, but implementing that makes it a bit more complex than just automatically requesting a certificate per nginx vhost.
Still, with enough automation, you can request 5 per week in a cronjob, which will let you get at least 40-something websites, even with the recommended 60-day renewal cycle. :-P
> Certificates/Domain you could run into through repeated re-issuance. This limit measures certificates issued for a given combination of Public Suffix + Domain (a "registered domain"). This is limited to 5 certificates per domain per week.
If SAN certificates make sense for your setup (i.e. all used on the same server or for the same service), you can have up to 100 (sub)domains on one certificate, or basically 500 per week.
I did a bunch of requests starting with one subdomain, then a second, adding SANs multiple times, setting a cron to do one request a month and testing it, then adding yet one more SAN to the list.
Let's Encrypt is awesome but you still need to have root access to the machine. I host my stuff on a shared 1&1 node and I can't seem to find any way to add SSL to my websites without having to pay them.
(Yes I should move to another host but that is too much hassle for me right now.)
I tried Caddy the other day and was pretty impressed. It's a single binary, it automatically installed a Let's Encrypt cert for itself and it had a bunch of other nice features.
I'm not going to switch production to it yet, but it's looking like it'll go on my home server pretty soon.
Seriously this. I don't see why encryption and website verification have been wrapped up in the same thing (SSL certs). They're two different things. Encryption should be free, automatic and default.
If you don't have a way to confirm that the key you're seeing from the other site is right, you're inherently vulnerable to a man-in-the-middle attack which removes the benefits of the encryption against the attacker.
It's not clear that the certificate authority system was or is the best solution to this problem, but it is a problem that calls for some solution. In the case of Domain Validation, we only try to confirm that the key is appropriate to use with the domain name, which is the smallest possible kind of confirmation that can be done to address the crypto problem. There's no attempt to validate or verify anything else about the site.
However, having one and not the other isn't totally useless.
Having the browser be able to track and tell me that "Though we aren't sure this is actually google.com, we do know that the exact same cert has been used the last 50 times you visited this website" is something I'd consider to be useful. (Actually, telling me if it changes would be the useful bit).
That would be at least be useful for self-signed certs (though those aren't really needed in light of Let's Encrypt...)
> (Actually, telling me if it changes would be the useful bit).
I'm curious. Has anyone ever encountered that scary warning you get when an SSH host key changes, and thought "oh man, I'm getting MITMed, I'd better not connect to this server!", instead of thinking "oh right, I guess they reconfigured the server, now what command do I type to make the warning go away"?
I have. Usually it's because i reconfigured the server, but I am ultra paranoid. Most people don't care, but I would expect sysadmins to do so. And who else should login with ssh?
I've never thought it was likely to be an attack, but I always thought it was my responsibility to check why it changed or at the very least confirm it looked the same via a separate network path.
Take a look at google's certs. They're only valid for a few months. A system that tracks certificates encourages site operators to share the same cert and key across many servers and to allow it to live for a long time. With the sorry state of certificate revocation this is not ideal.
On the server side it's better for each server to have it's own private key and certificate which is valid for a short period of time and frequently renewed. So the compromise of one server does not compromise certificates on any other servers and the useful lifetime of a compromised key is very limited.
I think DNSSEC and DANE is the best solution. Allow the certificate thumbprints to be published securely in DNS. At least then we reduce the number of trusted authorities to the TLDs and the scope of authority for each one is automatically restricted to it's own TLD.
> However, having one and not the other isn't totally useless.
> Having the browser be able to track and tell me that "Though we aren't sure this is actually google.com, we do know that the exact same cert has been used the last 50 times you visited this website" is something I'd consider to be useful. (Actually, telling me if it changes would be the useful bit).
Isn't that what you do when you make a security exception for a self-signed certificate? Having that enabled by default lulls people into a false sense of security.
Be nice if self-signed certs were compatible with vanilla HTTP. Then no warning or complaint from the browser, but minimal security boost over naked transmission.
> Seriously this. I don't see why encryption and website verification have been wrapped up in the same thing (SSL certs). They're two different things. Encryption should be free, automatic and default.
Becuase you either have to do DH and all of the key negotiation anyway (at which point you already have a key, so why not encrypt and HMAC at the same time?). If you had two systems for this, it would be pointlessly inefficient (why have two DH key exchanges for the same channel).
Because without a trust anchor (a certificate), encryption is pretty much worthless against MitM attacks.
You need a way to verify that the site you're connecting to really is who it claims to be before you can trust even an encrypted connection to that site. Otherwise you don't know whether you just established an encrypted connection to the website, or an encrypted connection to a malicious attacker.
SSL/TLS actually does support unverified encryption, but browsers have decided to disable it because the UI for "encrypted but non-verified" is deemed too confusing for users.
SSH gets this right -- create a host key when the server is installed, and have the client check the key and only warn/error when it changes. Sure, this isn't super-secure for first time visitors to their banking website or whatever, but those websites can continue to use the current system.
SSH doesn't get this right. It's no better than a (auto-pinned) self-signed cert, in our world.
I challenge everyone to find in their extended group of friends and colleagues, and their friends and colleagues, a single person who consistently checks the fingerprint* on every first SSH connection.
Id personally have a hard time finding someone who even knows it matters.
And if you don't? Mitm can get your password, or tunnel your key to another host, bar some crazy ~/.ssh/config which nobody has.
WiFi's WPA2 actually does this better than SSH; the passphrase authenticates both parties to eachother, not just one way. I can't set up a hotspot with your home SSID and intercept your PSK---even on initial connection.
SSH: nice in a cryptographic utopia, not better than self signed SSL certs when applied to human beings.
SSH is just not suitable for humans. Apparently.
* a significant part of it, not just the security-through-obscurity random 2 letters in the middle and the last four.
Still, there's a difference between being less than 100% secure and being a totally useless feature.
Being able to make the statement "Either you've been consistently MitM'ed by the same entity for the past three years, or the your little cloud-based debian box is actually secure" is a lot more useful than not tracking SSH fingerprints at all. I certainly wish my browser would track my self-signed certs in this way.
Without going into the question of how many bits of entropy that actually has when used with human beings in real settings, and just assume it's a perfect check; my question stands: how many people can you find who use this?
Many SSH clients don't even support it, at all. PuTTY and almost anything that uses SSH for tunneling.
When they do: how many of your hosts do you know the image of?
Again: nice idea, but utterly impotent in our universe.
Compare to the efficiency of e.g. WPA2 keys: less theoretically beautiful, but much more efficient with humans.
>Without going into the question of how many bits of entropy that actually has when used with human beings in real settings, and just assume it's a perfect check; my question stands: how many people can you find who use this?
Probably not very many, but it's really only useful for people that ignore basic security features anyway. (Key auth)
>When they do: how many of your hosts do you know the image of?
None, I use key auth like any reasonable person would.
Does key auth protect you from a MITM on the first connection?
That is, key auth as reasonable people use it, as you said.
And this:
> but it's really only useful for people that ignore basic security features anyway. (Key auth)
is precisely the point: that's a lot of people. SSH doesn't work for those people. We can play the blame game, but at the end of the day, clearly something is "not right".
And these are people who use SSH to begin with. Not typically technologically illiterate, I would guess. If they can't even be arsed to use "basic security features", what good is this system, then?
Again: there is a way to use SSH properly, yes. But rare is the person who does this.
(But key auth is orthogonal to host fingerprinting anyway, this is kind of a red herring)
>Does key auth protect you from a MITM on the first connection?
Yes. Key auth will protect you from your SSH connection being listened to, and will make credential theft reliant on social engineering. However, someone could still pretend to be the server (potentially stealing your commands), but there really doesn't exist any way to solve that.
>is precisely the point: that's a lot of people. SSH doesn't work for those people. We can play the blame game, but at the end of the day, clearly something is "not right".
Nothing works for those people, at least generally with SSH users you can assume that they should know better.
>Again: there is a way to use SSH properly, yes. But rare is the person who does this.
I'd hardly consider SSH key auth users rare.
>(But key auth is orthogonal to host fingerprinting anyway, this is kind of a red herring)
But it almost completely fixes the main problem caused by MitM, someone gaining access to the server you're logging into.
When was the last time you verified a host key out of band?
And if you're using SSH, you know well enough to know why you should do the damn legwork to verify the key. What do you expect for end users?
Furthermore, if nobody is doing out of band verification on the first pass, how do you expect users to distinguish between an attack and legit host key change?
As I said above: Sure, this isn't super-secure for first time visitors to their banking website. But it's fine for the common case where someone tries to MITM you when you move from your home to a coffee shop or vice versa and you're just browsing sites that would otherwise be using http.
But the worst case scenario with SSH MitM isn't someone being able to eavesdrop on your connection. But someone pretending to be the server, which is hardly as serious. (Unless you're using password auth, in which case you deserve to get owned)
If someone impersonates your server, it can then pass the authentication request to the original, and gain full MITM without your knowledge. Yes, even if you use public key auth.
I will personally pay you the sum of 500 Bitcoins if you can demonstrate a realistic active MitM attack on OpenSSH that allows an active network level attacker to "pass the authentication request to the original" and gain full MitM.
Conditions:
Public key authentication must be used for authentication.
If it's possible to perform the attack passively(e.g on pcaps), it doesn't qualify.
This attack has to affect setups using both the latest OpenSSH client and server with default configuration.
This attack has to be able to be performed in realtime using the processing power of a 2015 macbook model of your choosing.
This attack cannot rely on attacker having any other access but the ability to tamper with the connection however much he wants.
This attack cannot rely on known flaws in the encryption algorithms.
With full MitM I am referring to the ability to at least access the plaintext communications between the client and server. Eg if the user runs 'sudo', the ability to see the password entered.
Please consider this offer legally binding, if you have any questions I will answer them and you can consider the answers binding too.
Seriously though. If secure is the default from now on, why can't it actually be the default?