Securing your Web server with SSL/TLS
- Thread starter JournalBot
- Start date
Nice article, you know your stuff and have a neck for explaining, even if you do open root shells the Umbongo way.
Upvote
1
(3
/
-2)
I wish there was a happy medium with self-signed certificates. It seems contrary to the open web that you have to ask the permission of third parties in order to offer your visitors encryption without having their browsers throw a conniption fit.
Upvote
5
(6
/
-1)
doornail":g2e6cjyq said:
visitor: are you doornail?
pancakes: yes I am doornail.
visitor: okay! where do i sign?
I think we should get 1 more opinion....
Upvote
15
(15
/
0)
doornail":3ofth6f9 said:
Adding extra layers in certain instances--like here--is a good idea. Although no system is foolproof, more steps will ward off some potential low-level shenanigans.
It may be good to view third-party authentication as a type of online independent audit.
Too many people online are shockingly cavalier about security--until they are burned.
Upvote
4
(4
/
0)
pancakesandbeyond":2of55b4u said:doornail":2of55b4u said:
visitor: are you doornail?
pancakes: yes I am doornail.
visitor: okay! where do i sign?
I think we should get 1 more opinion....
The point doornail made was "are you doornail?" is the wrong question. There are other ways to verify identity than with a certificate.
Upvote
4
(6
/
-2)
pancakesandbeyond":2o9zdks2 said:doornail":2o9zdks2 said:
visitor: are you doornail?
pancakes: yes I am doornail.
visitor: okay! where do i sign?
I think we should get 1 more opinion....
The thing is, we currently have three basic modes:
(1) No SSL
- DOES NOT PROVIDE encryption
- DOES NOT PROVIDE authentication
Result: browser connects and acts normally, no warnings, no lock icon
(2) SSL with valid certificate
- Provides encryption
- Provides authentication
Result: browser connects and acts normally, no warnings, shows lock icon
(3) SSL with self signed certificate
- Provides Encryption
- DOES NOT PROVIDE authentication
Result: browser raises holy hell, big red warning dialogs, Danger, Will Robinson! FRAUD! HACKING! SCAMS! SPYING! RUN! HIDE!
I'll accept that Case 3 is no more secure than Case 1, but I reject the notion that it is any less secure than Case 1. Yet the browser treats one as no big deal and the other as the end of the world.
Upvote
15
(17
/
-2)
owdi":3k5cbs3e said:
This is why Browsers throw up the red warning page. anyone can self -certify a cert claiming to be anyone.
what other way can you verify identity other than checking with a 3rd party?
doornail would have to transmit his cert to his vistors by e-mail or some other such way, and his visitors could then store it in their keychain but that's clunky and requires a lot of (relative) effort on doornail's part.
Upvote
2
(2
/
0)
portent":2fa78njd said:
From the browser's point of view. If the site requires encryption, then the information being transmitted is probably important and sensitive. If that's the case then the identity of the site should be verified. The user may get lulled into a false sense of security thinking that just because their traffic is encrypted that the site is who it says it is.
Upvote
8
(9
/
-1)
portent":3j2a7vod said:
The difference is though that sites running unencrypted and unsecured content generally don't try to push sensitive data down to you and acquire sensitive data from you. At least when you buy a certificate from a proper CA, you've got at least a little assurance that yes, Crazy Joe's House of Computing have bought this certificate, they've proven that they are in fact Crazy Joe's House of Computing and that once you press that submit button, your credit card details will be sent to Crazy Joe's House of Computing rather than Crazy Ivan's Retirement Fund.
Having a self-signed certificate doesn't give you that kind of assurance and this is why browsers flag up when the cert is untrusted and when there's a name mismatch.
Upvote
2
(2
/
0)
pancakesandbeyond":1m1z13dy said:doornail":1m1z13dy said:
visitor: are you doornail?
pancakes: yes I am doornail.
visitor: okay! where do i sign?
I think we should get 1 more opinion....
As Owdi mentioned, we're collapsing two separate problem domains. We have encryption based on open standards. Your browser supports it, my server supports it. The quality of this encryption does not suffer because I generated the certificate myself. Heck, I could argue it's higher because only *I* have a copy of it and it's never transmitted by whatever medium.
Authentication definitely has value -- but, IMHO, I think it makes an in-elegant conjoined twin.
Upvote
1
(2
/
-1)
Lee Hutchinson,
you're becoming my favorite Ars Technica writer.
Keep on with the excellent work.
you're becoming my favorite Ars Technica writer.
Keep on with the excellent work.
Upvote
8
(8
/
0)
doornail":1ju98mol said:
hypothetically, Let's say I am a competitor, and I want to divert your customers underhandedly. I will set up a similar looking domain name and also provide a self signed cert. I will also send out suspect e-mails trying to trick people to come to my site.
New customers wont know that it's not you and I'll steal their business. Existing customers knowing that your cert was self signed may think that you just changed your cert for whatever reason (my fake e-mail alerts them to a cert change with instructions on how to get a new cert) and accept a new cert.
Not all will fall for this, but a percentage will.
The browser is looking out for this kind of behavior.
you may not be running this kind of site, but the browser doesn't know.
Upvote
4
(4
/
0)
I know they aren't the only one, but given StartSSL had issues last year (http://www.theregister.co.uk/2011/06/21/startssl_security_breach/), is it a good idea to suggest them when talking about security?
Upvote
-3
(1
/
-4)
dlp":28us1v3v said:
On the contrary, it shows that unlike Comodo and some other certificate issuing companies, they use a proper layered approach to security:
Upvote
6
(6
/
0)
Why use Linux? You could do this much more sanely and securely with FreeBSD (Jails, etc) and get a performance enhancement to boot!
Upvote
-13
(2
/
-15)
doornail":3dalrxb4 said:
High, I'm a self-sign cert for YourBank.com... you can trust me.
Certs are mostly to trust. Your trust is only as good as your weakest link. Any hacker out there can create their own cert, but it is relatively hard to get a highly rated cert from a CA.
As much as I don't like some CAs, I still trust them more than a random Internet user.
Upvote
5
(5
/
0)
Aside from the "costs an arm and a leg" claim (you can get a 1-year RapidSSL cert for $15 from ClickSSL), this was a very informative article
Upvote
1
(2
/
-1)
I'm waiting for when Lee explains how to set up your own VPN server so you can access facebook from china
Upvote
5
(5
/
0)
Please next article be a home server with media server, samba/nfs owncloud, backup, subsonic, etc.
Upvote
1
(1
/
0)
Aw, there doesn't seem to be an option for multiple subdomains for free SSL certificates. Unless I pony up some $50. As it is, this seems to be pretty limited, since you can't use the same SSL certificate with a home server and say, Bluehost together. They'd require separate sub-domains... and the Bluehost would take up the standard domain and the www one too.
EDIT: I guess the way around it is to use multiple certificates for separate sub-domains. I can see this getting unwieldy though with more than a few sub-domains...
EDIT: I guess the way around it is to use multiple certificates for separate sub-domains. I can see this getting unwieldy though with more than a few sub-domains...
Upvote
1
(1
/
0)
Well, the "correct" way to do is is to pay for the identity validation, and then get a wildcard certificate. That's actually what I did--I have one for *.bigdinosaur.org which covers all my hosts there, and one for *.chroniclesofgeorge.com for the hosts there.
A wildcard cert is actually crazy-useful--in addition to web sites, I'm also using my *.bigdinosaur.org cert for my firewall's web interface (so it doesn't throw SSL errors when I access it) and also for my domain's Openfire instant messaging server. Once you get a wildcard certificate, it starts being useful in all sorts of places.
A wildcard cert is actually crazy-useful--in addition to web sites, I'm also using my *.bigdinosaur.org cert for my firewall's web interface (so it doesn't throw SSL errors when I access it) and also for my domain's Openfire instant messaging server. Once you get a wildcard certificate, it starts being useful in all sorts of places.
Upvote
6
(6
/
0)
I get that. I'm not saying that an encrypted, unauthenticated connection should be presented as being equivalent to an encrypted, authenticated one. It should not display the "lock" icon or the "green bar" or any of the other reassuring hints that browsers give users that a site is secure.pancakesandbeyond":3e2vh1k0 said:
I just think that it should not be treated as somehow more dangerous than an unencrypted, unauthenticated one. It's certainly not secure, but it's not any more dangerous than a "normal" non-SSL connection.
To go further, I think there should be different behavior for the different kinds of "bad" certificates. A revoked certificate (or root) should probably be flagged as it is now. An expired certificate...probably the same. A certificate for the wrong domain name...maybe it should prompt the user to check their network and/or DNS settings? A self signed certificate should not show a lock or a green bar or "https, but should not be treated as somehow more dangerous than a non-SSL site.
And while we're at it, I'd like HTTPS Everywhere to be the default behavior of every browser.
Upvote
1
(2
/
-1)
The problem I have with ID validation for wildcard certs is that it's personal validation that requires exchanging a lot of private information. I can see why they want to do it, but sending photocopies of my passport and driver's licence to some company doesn't exactly fill me with warm and fuzzies.
bartfat: depending on what you need to do, if you're hosting this yourself it can be simpler to set up a series of virtual hosts at the same domain name rather than using subdomains and having to get certs for all of those or a wildcard cert.
Instead of site1.yourdomain.com, site2.yourdomain.com, etc. it's simple enough to configure apache to serv http://www.yourdomain.com/site1, http://www.yourdomain.com/site2, etc. If you need it, each site can still have its own separate authentication set up so that users for site1 can't get into site2.
At that point, a single cert for http://www.yourdomain.com is all that's needed.
bartfat: depending on what you need to do, if you're hosting this yourself it can be simpler to set up a series of virtual hosts at the same domain name rather than using subdomains and having to get certs for all of those or a wildcard cert.
Instead of site1.yourdomain.com, site2.yourdomain.com, etc. it's simple enough to configure apache to serv http://www.yourdomain.com/site1, http://www.yourdomain.com/site2, etc. If you need it, each site can still have its own separate authentication set up so that users for site1 can't get into site2.
At that point, a single cert for http://www.yourdomain.com is all that's needed.
Upvote
0
(0
/
0)
That turns into a sticky issue, though. The ultimate purpose of encryption isn't to hash your data, but rather to ensure that it's not going to be read by anyone other than the intended recipient. Encryption without end-to-end authentication means that you're sending your scrambled bits to...someone. The connection may or may not have an eavesdropper; there might or might not be a man-in-the-middle.portent":247q8402 said:
Ensuring you know who you're talking to is just as important as the actual scrambling of the data, and some kind of warning really is necessary.
Upvote
6
(6
/
0)
Or, if you only need a few (known) subdomains, you can get a UCC certificate, which covers up to 5 hosts, and are a little cheaper than wildcards.
But yeah, I love wildcard certs; it's nice having one for here at work, so I can turn up a random subdomain for dev work, and still be able to use SSL.
Upvote
3
(3
/
0)
That, though, is the entire purpose of a Certificate Authority. They must verify you are who you say you are. Their validation of you in turn enables everyone else to trust the certificates they issue. A CA vouches for the identify of the people behind the certificates, and a CA is only a trustworthy CA when they actually do those things.Smeghead":3nejutx9 said:
A wildcard cert is more flexible and more trusted (in the sense that it covers more hosts) than the freebie certs, and requires some more validation to ensure it's being given to someone who is a real person and who has control over the domain the cert covers. Typically, the more "powerful" a certificate is, the more validation must be done. As I mention in the piece, that's the reason behind the high prices on extended validation certificates--look up the validation requirements on those. This kind of thing really is where the digital world crosses over into the physical--an EV cert requires tons of documentation.
edited to add - brodie's UCC cert suggestion is a good one and might also work for you!
Upvote
3
(3
/
0)
Great article, got me going again on my webserver. A couple of things I'd like to add.
1. There's a typo in the virtual host configuration file:
ssl_certificate_key etc/nginx/conf/ssl.key;
should probably be
ssl_certificate_key /etc/nginx/conf/ssl.key;
For copy-pasters this is a big deal, otherwise, just categorise it as nitpicking
2. If you're using a commercial certificate from Comodo, Verisign etc, there's an extra line you can add to factor in the root and intermediate certificate
ssl_client_certificate /etc/nginx/conf/ca-bundle.crt;
Regards
dieb
dietbrand.eu (don't worry, you'll get redirected \o/)
1. There's a typo in the virtual host configuration file:
ssl_certificate_key etc/nginx/conf/ssl.key;
should probably be
ssl_certificate_key /etc/nginx/conf/ssl.key;
For copy-pasters this is a big deal, otherwise, just categorise it as nitpicking
2. If you're using a commercial certificate from Comodo, Verisign etc, there's an extra line you can add to factor in the root and intermediate certificate
ssl_client_certificate /etc/nginx/conf/ca-bundle.crt;
Regards
dieb
dietbrand.eu (don't worry, you'll get redirected \o/)
Upvote
0
(0
/
0)
And yet the browser displays no warning whatever if I connect to an unencrypted plain-HTTPsite, which does neither scrambling nor authentication.Pokrface":3s4iah2y said:
"But," you say, "Everyone knows that plain-HTTP sites are insecure. Nobody would ever submit personal information to a plain-HTTP site."
Well, that is, in fact, how every phishing link I've seen in the last few months works.
I am not trying to say that Self Signed is equivalent to CA Signed. I'll even readily accept the proposition that Self-signed is effectively no better than unencrypted.
My only beef is with the idea that self-signed is somehow more dangerous than unencrypted. Yet this is the stance that browser UIs take.
Upvote
1
(2
/
-1)
Even my 86 year-old grandma knows how to look for the little lock in the corner.
So yes, there is a certain expectation of privacy if a connection is encrypted. If the connection is not verified, that expectation is not necessarily true, so it bears calling attention to it.
With HTTP, there is no expectation of privacy (or there shouldn't be), so there's no reason to call attention to it.
So yes, there is a certain expectation of privacy if a connection is encrypted. If the connection is not verified, that expectation is not necessarily true, so it bears calling attention to it.
With HTTP, there is no expectation of privacy (or there shouldn't be), so there's no reason to call attention to it.
Upvote
0
(1
/
-1)
I disagree with you (and cite every phishing site in my spambox as my evidence) but thank you for at least challenging my position without assuming I don't understand what CAs do.brodie":lhrspw40 said:
Upvote
4
(4
/
0)
It's because encryption carries with it the promise of security. It's sort of the difference between saying, "Don't take your pants off and walk in front of that window, everyone will see you naked!" versus, "Oh, yeah, you can totally take your pants off in front of that window because it's painted over." You're free to take your pants off and walk in front of the window either way, but the expectation is there in the second case that no one will see you doing it, and you'd be more likely to go for it. With CA-validated cert, you've at least got the word of a certified window painter that the window is painted over, whereas a self-signed cert could be signed by, well, anyone.portent":39z2v7ud said:
The proverbial "reasonable person" (to borrow a legal term because it kinda fits) is more likely to communicate private things via encryption. Signaling that encryption is in place, without verifying that things are going to the intended recipient, means a reasonable person might communicate something sensitive to an eavesdropper or attacker. Anyone can self-sign a certificate to represent any host--I can sign a cert saying that I'm http://www.google.com if I wanted to.
Upvote
3
(3
/
0)
How does a phishing site's attempts have any bearing on people's awareness of SSL?portent":ucr4vlbj said:
If they started sending out gopher:// links, it wouldn't mean that people would suddenly gain knowledge of what that protocol was.
How many hundreds of thousands, or millions, of those emails get sent out, and how many people buy into it? I would bet that at least 70% of people who even got fooled enough to click the link would check for the lock in the corner once the page loaded. Of course, that's entirely anecdotal, so that take that for what it's worth. (In that vein, my dad can't help but click links... it's almost a compulsion; but I've taught him to at least look up and see if it's protected before entering a password or anything sensitive).
Upvote
0
(1
/
-1)
- Status