You want to put your credit card number into a web site. You know to look for a secure web site. But what does that really prove? And now that so many electronic projects have Web servers (ok, I’ll say it… the Internet of Things), do you need to secure your web server?
There was a time when getting a secure certificate (at least one that was meaningful) cost a pretty penny. However, a new initiative backed by some major players (like Cisco, Google, Mozilla, and many others) wants to give you a free SSL certificate. One reason they can afford to do this is they have automated the verification process so the cost to provide a certificate is very low.
That hasn’t always been true. Originally, trusted certificates were quite expensive. To understand why, you need to think about what an SSL certificate really means. First, you could always get a free certificate by simply creating one. The price was right, but the results left something to be desired.
A certificate contains a server’s public key, so any key is good enough to encrypt data to the server so that no one else can eavesdrop. What it doesn’t do is prove that the server is who they say they are. A self-generated certificate say “Hey! I’m your bank!” But there’s no proof of that.
To get that proof, you need two things. You need your certificate signed by a certificate authority (CA). You also need the Web browser (or other client) to accept the CA. A savvy user might install special certificates, but for the most utility, you want a CA which browsers already recognize. Actually, it is a little more complicated than that. Your CA might be recognized by another CA. That CA might be recognized by yet another CA. This can go on for awhile. The browser just has to trust one of the CAs in the chain.
That means the CA effectively is vouching that you are who you say you are. In the old days this was a laborious process and required the CA to prove your URL, your company name, your address, and other details. Today, most certificates only validate the URL. It is up to you to go to the correct URL.
This makes CA verification much simpler, however. With the Let’s Encrypt verification, you must have the right to either configure a DNS record or place a file on the server — a process with which webmasters are already familiar. The automated process will verify that you actually made the change and, thus, prove you own the domain.
Let’s Encrypt will soon become part of the Electronic Freedom Foundation and will get a new name. However, they’ve issued over a million certificates. Most browsers and operating systems will work with the certificates, although there is some limitation with Windows XP.
The whole SSL system generally works well, but it isn’t perfect. We’ve covered some certificate security problems with Google before.
As Web servers become more prevalent in electronic projects, a source of free and trusted certificates will come in handy. You can watch a video of the installation process below.
One thing that really pisses me off about the various browsers is the hate for self-signed certs. When you visit a webpage that has a self-signed cert, you get a big red background page and warning and alert boxes and all these other things. Yet when you visit a TOTALLY UNENCRYPTED WEBSITE, you get nothing.
Which means they literally consider plaintext http:// as somehow BETTER than a self-signed certificate.
What the hell.
Follw the money :-)
“One reason they can afford to do this is they have automated the verification process so the cost to provide a certificate is very low.”
And the other reasons are…. ?
Very low adds up.
Deep pockets. You saw the names. These companies will benefit from this and they can probably write the cost off at tax time.
If your browser don’t know the cert it may well be worse. If, during a MItM someone sslstrips your connection, it is noticeable that websites no longer have the green lock in their url. More importantly stored credentials are usually not used if the page used to be https and is now http. However if a self-signed (Or signed by an unknown entity) gmail pops up and no warning is given stored passwords and cookies will work as in the original, and no obvious signal would be visible to the user (Unless they check the certificate issuer every time or use cert patrol).
*MitM
Naw, I’m good with the warning messages when the SSL certificate changes to something unexpected… or uses an outdated cipher, or whatever other trickery. Self-signing just means there’s no “chain of trust” that leads back to some browser-dev sanctioned authority. You still get to have encryption to the server though, and protection from eavesdropping on the wire, even if the server itself is not vetted.
Without a chain of trust you don’t have protection from eavesdropping. If you’re willing to accept a certificate that you don’t know, and that doesn’t chain up to an authority that you trust, then an eavesdropper can insert itself between you and the server you think you are talking to.
This all just dodges away from the point: browsers ‘just work’ when the connection is plaintext. You’re more likely to be eavesdropped then, because it’s trivial to do so. Add encryption and suddenly “WARNING WILL ROBINSON! DANGER! DANGER!” when it’s obviously still better than plaintext. Then, you have to click through a series of bewildering, half-hidden options to proceed to the page (varies by browser). Sometimes, I can’t figure out how to view the page at all.
Being /warned/ is fine and all, but the browsers aggressively *inhibit*. The assumption that only ‘really important’ websites use HTTPS is part of the problem. Coupled with the expense and complexity of installing SSL certs, it has kept the WWW in plaintext when it should have all gone encrypted-by-default decades ago.
I host a number of sites using Virtualmin management software – I just discovered that they’ve added “Let’s Encrypt” as a 1-click, 5-second install. Holy smokes, it works beautifully!
@Chad – the idea there is that if a site is HTTP, it is intended to be that way and wont be hosting any sensitive info, so there’s no need to warn about it (gardening info sites, for instance, or HaD), however if a site uses SSL then it means its trying to keep something secure, and you should be warned about anything insecure in the connection. And yes, a self-signed cert is insecure.
@foo: HTTPS is appropriate for all web sites now. Except maybe someone’s legacy Windows Mobile fan page. What’s holding us back is the ridiculous expense of a cert*, and this pervasive myth that HTTPS is for serious business, while HTTP is for “Patriots” who have nothing to hide. Sheesh.
HTTPS using self-signed certs is more secure than nothing at all. That’s just a fact. The impression given by the browsers incites FUD. Browsers shouldn’t say “Warning! You’re navigating to a dangerous, encrypted website!” They should say “Yay, your connection is encrypted. I will store the cert and warn you if it changes later”
*because we’re paying them to remove an encumbrance, not to perform a service.
@foo @chad Sites with self-signed certs should show up like mixed-content sites do in chrome. No ‘green lock’ icon but they still connect just fine. Don’t want to mislead users about the security they have, but don’t want to scare them unnecessarily either.
Just educate yourself and/or stop being lazy, setup your own CA and sign your certs with it, a free tool such as XCA makes this very easy even for the novice. To ensure security then, just install your root CA into your browser so it trusts all the certs you generate, and will detect a MITM attack.
You already know that “http://” doesn’t protect information over the wire, so you don’t need to be warned about that. The problem with self-signed certificates (that aren’t known to your browser ahead-of-time) is that they offer no protection against a man-in-the-middle, breaking the expectations that you have for “https://”. That’s why you need to be warned.
The Layman doesnt know the difference between http and https.
no, but the webadmin does. If they set a server up as HTTP, then it *should not* be serving anything that needs to be encrypted and therefore no warning is needed.
@foo, your argument stands weak in the wake that Google (in 2014) announced that secure sites should be used everywhere and they’ll soon start ranking secure sites higher than the unsecured ones. That affects all, even the ‘gardening’ and ‘personal blog’ site. So browsers should give a warning, maybe a Red icon with broken lock may be, but definitely it should not be intrusive and prevent user by default from opening a website with self signed cert. Warning is one thing and preventing is another.
Yep, it annoys me as well. If I want to access my Synology box, it gives me a warning every time. I just made a bunch of subdomains for the domain I own + free ssl certificate service from startssl.com
No/Bad security may be worse than no security at all. When you go to a plain-text site you (should) know not to trust it. When you’re going to site that’s using a self signed cert it’s good to know that even though the traffic may be encrypted you can’t verify the site is who it claims to be.
In reality, self-signed certificate is much more secure that all that signed thing. Browser or any other client using encryption have a list of “trusted” CA. But the question is – are they really trusted and by who? You have no chance to check if one of this “trusted” CA signed fake certificate for some agency or company. And yes, this is already happened at least twice. And the worst thing is that failed CA’s was not immidiately removed from the list of “trusted” CA’s. Just check your list in browser and you’ll find here CNNIC CA which is still “trusted”.
When you use self-signed certificate, there are only one real way to break encryption – to stole somehow your private key. (Let’s not speculate on quantum computers and other sci-fi stuff) When you use certificate signed by some authority, somebody can “ask” authority to sign certificate for your domain and MitM you, or fake “protected” site. It can be money, or national interests, whatever, but CA much more vulnerable for that kind of pressure.
Who can guarantee, that all that “free certificate signing” authorities will not sign third-party certificate for your domain? Nobody. All that bullsh…t about “removing failed CA” just not working at all. And even if it will work as expected ( immidiately remove CINNIC forever from list of trusted CA’s, or any other national of international CA in case of signing wrong certificate without taking in mind all that politic and finacial things ) who will remove failed CA from some closed source embedded system without updates?
So, Let’s encrypt, as any other “free signing” CA is not a solution at all. Self-signed certificate is much better. Once you accept it, browser will not alarm you, while certificate is valid.
Another argument is implicit, but still good. Just think about money. Why the certificate signing was relatively expensive thing for years, but now, suddenly, some business monsters (Cisco, Google, Mozilla, and many others) want to give you that previously expencive service for free? They do have profit, indeed, it is what they are. But what is their real profit on that “free signing” thing? Good PR around small server admins? I doubt.
Their are two cases where you will see the warnings for the self-signed certificates. Of course you are annoyed about the first: some server not able or willing to pay a CA .
But the warnings are for the second case: when you go to https: //your bank.com, on the free WiFi at the airport. Then it is an indication that a bad guy is intercepting your traffic to get at your bank credentials……
That’s not the point. The point is that when you go to https://your.bank.com you have no any chance at all to be shure that it is really your.bank.com and not something that just uses counterfeit certificate signed by some “trusted” CA, say CNNIC (because you are in some China airport) or Let’s Encrypt (because Google wants to know what you are paing for). And there will be no indication at all. And nobody will even ban that CNNIC or other authority who already caught or will be caught on signing counterfeit certificates. And even if they will, how long ago you updated your system or browser CA list?
All that “trusted CA” thing is a big bomb already ticking in your system. It’s just a matter of time when that system will be corrupted for money or state interests.
As for “annoying banners” – they just do not annoy me at all. It’s very useful thing for initial check that you really connects to server you want and for checking validity of already accepted certificates.
This a what certificate pinning is for : an ugly patch on an broken design. Secure, centralized and trusted in the same sentence ? D’oh !
Quote: ” “trusted” CA signed fake certificate for some agency or company. And yes, this is already happened at least twice”
and one of these times was MicroSoft
I don’t see how self-signed helps against “man in the middle” attacks. If I can intercept and change your traffic, I can just serve you my own self-signed certificate. As my self signed certificate is just as valid as yours, your browser will also accept it.
daid: not every threat comes from someone who controls the network. Self-signed certificates certainly protect against others listening on the same network. I won’t be forced to choose between no encryption and bona-fide 100% deluxe certified encryption.
Quote: As my self signed certificate is just as valid as yours, your browser will also accept it.
No. It is not valid, until you accept it. Browser will throw message that certificate is differ from certificate you accepted earlier and you will see that something is changed, unlike with fake certificate signed by “trusted” CA’s.
The point of self signed certificate is same as ssh public keys. When you connect to a site for a first time, ssh will ask if you want to accept the site’s public key. Once you accepted it, it will only bother you if the key has changed. This happens quite often when the server has been re-imaged or it is a temp server with a DHCP IP. But otherwise works fairly well.
But the real question is, can you trust the key when it is offered to you the first time. When you switch a browser, months after your initial deployment, can you trust that certificate? I think in order to use the self-signed certificate properly, you should carry the public key just like physical ID. You should pre-install the self-signed cert instead of relying on the browser to warn you and install.
It’s about to change :)
soon, they will alert the user (with the logo in the address bar in firefox nightly) if the website use a plain connection
Yeah, how funny that I posted this and then updated Firefox the next day. Now I have a little “I”nformation circle in the top left that informs me “Your connection is not encrypted!”
Also, if you need a valid certificate and don’t want / can’t use Let’s Encrypt, you can still get free ones (must be renewed yearly) from StartCom: startssl.com
That’s what I’ve always used. They even improved their website a bit recently.
One limitation though with StartCom, they don’t permit subdomains. Most of the stuff I want to protect are sites on subdomains that nett me no income, so it’s not economic to purchase a certificate from a recognised CA.
Are you sure? I have been using them for years on subdomains. I just got one issued CN = ap.asmetrics.com 60 seconds ago. Maybe you mean on subdomains where you don’t have any authority on the parent domain?
They don’t give away wildcard certificates, so you need a cert for each subdomain, which is a PITA if you have many subdomains.
Starcom seems like a good idea until you realize they charge you to revoke a cert. They are money-grubbing assholes.
https://www.techdirt.com/articles/20140409/11442426859/shameful-security-startcom-charges-people-to-revoke-ssl-certs-vulnerable-to-heartbleed.shtml
and also not so much safer: http://oalmanna.blogspot.de/2016/03/startssl-domain-validation.html
Signed certs might protect you from MitM attacks from YOUR government but apart from that MitM attacks are not common.
Usually when credit card details are taken, it a whole database load of them done with sql injection ie nothing to do with encryption or MitM.
If MitM attacks had been easy, they would be exceedingly easy to perform anywhere an open (or known password) WiFi network exists. All you’d need is a “WiFi pineapple” running a proxy server and a bunch of fake certs for popular banking websites prepared in advance.
The reason they aren’t common is because of the screaming red warning screen your browser gives you.
Since I’m commenting anyway, I am so glad letsencrypt exists. Now I don’t have to jump through a bunch hoops installing certs for my own CA in every app from which I might visit my own servers (mail app, multiple web browsers, etc), plus everyone who visits my website gets a green lock. :D
DeDe
vicevice
So should I go for the MitM attack (with a pineapple if that is your preference) in the airport lounge where there are at least 500 people and hope that *some* of them log into their bank accounts (where I have to be in the same place that the crime is committed)
… OR …
do I just download a database of 10,000 user details that includes credit card details from a another country? where the jurisdiction of the tageted countries law does NOT extend to where I am?
Yeah, lets skip rocket science – this is a no-brainer.
Doesn’t anyone remember FireSheep? The FF plugin that grabbed any Facebook session tokens out of the air on a public wifi connection (i.e. coffee shop) and then make it point and click easily to impersonate that user’s session? It was done as a protest at the lack of SSL on Facebook, and a few months later, Facebook (and other similar entities) went 100% SSL.
Session hijacking and similar attacks are wicked easy without SSL.
I just went through the process of setting up letsencrypt for a few of my apps I have behind nginx on a friend’s FreeBSD server. Even reading through tutorials and stumbling a little in an unfamiliar environment, it only took me a few hours and now I never have to touch it again.
Oh, and adding new sites to it is simple. Run letsencrypt with the new domain, copy/paste the nginx block.
519 open issues with ones going back into 2015 unanswered?? Not confidence inspiring. Yeas, some are trivial or ask a question but clearly the oversight on this project is lacking. More Google Android quality at work???
Is there a step-by-step description in English somewhere for how to actually use this?
I went to their site, but its all in Linux quantum state space cadet gibberish.
I just simple programmer, and install instructions where step 1 starts AFTER you have things up and running, scares and confuses me…
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto –help
Yeah, i dont know what that means.
Is that for people who use git only?
Because I don’t.
If you want, you just have to download the zip with the tool you want.
Ok then.
Start with the URL to that zip-flie, and the name of the tool.
With “tool” do you mean a regular exe-file, I click it, and its running?
Or are there any additional steps, if so, which ones?
If you’re going to run a server on the Internet, I strongly suggest you =LEARN= this stuff, or you’re liable to fall prey to a black hat.
git may sometimes live down to it’s name for user friendliness, but it is still well worth installing and learning the basics. Also, learn how to use man pages to check what a suggest command line does. Not everyone submitting help online will actually be safe with their suggestions.
I’m definitely not going to use this.
Since the documentation is all but non existent, and the software seems to be a cobbled together mess from countless people.
I don’t put shit on a site, if i don’t know what it does.
And the fact that you don’t understand it and it scares and confuses you.
You also can set up a tor hidden service.
It’s quick, easy and you can provide different level of security for your website.
“…new initiative backed by some major players (like Cisco, Google, Mozilla, and many others) wants to give you a free SSL certificate.” Yeah, the Fox built my hen-house, and kept the keys. Letting anything associated with Google even remotely near your life is dangerous. Google = Evil.
SSL is best understood first and then implemented. People who have no idea what SSL is, end up screwing their websites.