FFS SSL
wingolog.org
wingolog.org
SSLMate [https://sslmate.com] sells SSL certs from the command line for $15.95/year. The sslmate command line tool takes care of properly generating the key and CSR, and properly assembling the certificate bundle containing the chain certificate. Certificates secure both example.com and www.example.com. No more hard-to-use websites or obscure openssl commands. I'm working on a config file generator too, so you'll be able to specify your server software and it will output a secure config for you.
And since the author mentioned out-of-process SSL termination, I'm also the author of titus [https://www.opsmate.com/titus/], an SSL terminator that is so paranoid it stores the private key in an isolated process (which would have been impervious to Heartbleed). It also solves the original IP address problem by using Linux's transparent proxy support - your web server sees the client's actual IP address even though the connection was proxied through titus.
On the other hand, if you want to go further into tinfoil-hat territory, find a way to isolate each process in a separate container. :) (Bonus points: Tear down/rebuild the container for each new connection.)
https://twitter.com/markloman/status/453502888447586304/phot...
(there was probably other sensitive content like emails in that dump too)
This kind of information is far more useful to attackers, since it can be used immediately and independently, whereas a compromised private key is only useful in conjunction with an active MitM attack (if forward secrecy is used) or a passive eavesdropping attack (if forward secrecy is not used).
As for containers, titus is already using a lot of container-like techniques, such as filesystem and network isolation, and I plan to use PID namespaces in a future version. So it's probably already deep in tinfoil-hat territory ;-)
Late edit: Ultimately this all comes down to a more general desire for better tools for segregating data and APIs into appropriate security domains. It's still way too much work, especially for small teams, to separate things into appropriate security domains with appropriate tradeoffs.
Do you sell Extended Validation (EV) certs?
No. The long and complicated approval process for EV certs
does not work well with the SSLMate model, which emphasizes
quick and simple SSL purchases from the command line.
Does SSLMate sell SHA-2 certificates?
Not yet, as our upstream certificate authority has
incomplete support for SHA-2 certificates.
We expect to add full support for SHA-2 certificates in Q4 2014.
And I know it's lame about the SHA-2 certs, but my hands are tied for now. We're not selling any SHA-1 certs that expire after 2015 so we're not running afoul of the deprecation schedule set by Google. (And if you do buy an SSLMate cert, we can reissue it as a SHA-2 cert but it's a manual process.)
Any chance of adding wildcard support? We need that.
www.example.com.crt - the certificate by itself
www.example.com.chain.crt - the intermediate certificate
www.example.com.chained.crt - concatenation of the certificate and the intermediate certificate
Most software, including nginx, takes the .chained.crt file. Apache takes the .crt and the .chain.crt file as separate config options.
Is it, because you re-sell?
If you have fewer than 10 hostnames to secure, definitely go with individual certs and use SNI instead of a wildcard cert. Support for SNI is quite widespread now, and SSLMate makes managing lots of certs easy.
https://www.gogetssl.com/wildcard-ssl-certificates/
(these guys also have a reseller program but I don't know what that price is)
* It's easier to set up. Having personally been through the situation in the article a time or two in my life, it sucks, and there's no reason for it to suck.
* The prices stop being extortionate. 10x price differential for a literal 1 bit change in the final product to make a wildcard cert? Fuck you! Everyone mentions StartSSL. Sure, the basic certificate is free.. if you don't miskey your domain name.. or you don't select the wrong options.. or OpenSSL doesn't get owned, in which case you get to pay $15 for the privilege of their server spending a few milliseconds of CPU time to spit a few kilobytes of data back at you that represents the thing you already had.
PKI as it exists today is a fucking scam. It's a scam because it's overpriced, it's a scam because it's exploitative, and it's a scam because it's incredibly easy to do things that render the whole exercise pointless.
Also, you might consider configuring your server to only support cipher suites that will be supported by TLS 1.3 [0][1] and let old clients get errors. If you need security, don't use the obsolete stuff the experts don't trust anymore.
0 - https://tlswg.github.io/tls13-spec/#rfc.section.1.2
1 - This means use only (ECDHE|DHE)-(RSA|ECDSA)-AES128-GCM-SHA256 and (ECDHE|DHE)-(RSA|ECDSA)-AES256-GCM-SHA384. No key exchanges that don't provide forward secrecy, no RC4, no CBC mode, no MD5, no SHA1.
0 - https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto...
To avoid a situation where future security improvements are held back by crufty configuration that was added in a well-intended effort to improve present-day security, I think we should be encouraging blacklists instead; the OpenSSL cipher list spec actually supports blacklisting.
[1]: https://github.com/cloudflare/sslconfig/blob/master/conf
Of course, you sound like exactly the kind of sysadmin I'm not concerned about ;-)
Now I give my recommendations as an ordered list of suites. It's easy to set up, does exactly what you want and, as a bonus, everyone can look at the list and understand which suites exactly are configured.
That said, I'd like to see good default configurations in libraries and server programs, which can be updated via patches as needed. Then we wouldn't really need to bother with cipher suite configuration at all.
tells you how to use StartSSL, which generates the key in your browser.
Whoops, your private key is now known to another server on this internet
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ke...
http://www.jroller.com/whoami/entry/browser_generated_certif... (2006)
You generate the CSR and send that.
But even so, unless you actually inspect the live DOM and ensure it's really using that element for your session, and inspect enough of the rest of the code to ensure it's not some misdirection, you can't really trust it.
no matter what practices startssl uses, once your connection to them is compromised or once they are compromised, then the attacker can change what practices startssl suggests to its users.
Or just issue a cert on its own accord...
or at least consult the md5 on your distill page before running it? oh and make sure md5sum is not altered either.
1.) Start the webserver
2.) Webserver: Oh look, I have a virtual host for example.com but no valid SSL certificate in order to serve https.
3.) Webserver: Generates a key+cert. Calls out to third party trusted SSL provider and says: "I control the website for example.com, please sign the following cert"
4.) SSL provider connects back to example.com to validate that the request for a cert is authorised, then signs the cert and gives it back.
This could work today, if a trusted third party SSL provider created such an API and Nginx/Apache were updated to talk to it.
Imagine if next time everyone did an "apt-get dist-upgrade" or a "yum update", their web servers suddenly started providing a HTTPS version of their site.
[edit] Step 4 is the equivalent of the way domain verified SSL already works today, except over HTTP rather than Email.
user@host:~$ apt-get install apache2
[...]
Please enter your credit card information to submit your SSL cert request.
And anyway, most websites don't need SSL. Anyone who tells you different is probably wearing an aluminum foil fashion accessory.
Encrypting the transport layer ensures that the marketing dribble your execs have written is exactly what your end users see (even in the airport or firesheep-infested coffee shop). And if you have any session cookies or collect email addresses anywhere on your site, that personal information should be a free lunch for Google and the NSA.
HTTPS is always a good idea, foil fashion optional ;-)
How about the fact that any HTTP page can be injected with arbitrary javascript by a MitM? Are you that confident about your browser's impermeability? Do you always use a VPN in public hotspots? etc.
Anything that's worth viewing, on an often attacked platform (browsers), is worth viewing securely.
edit: s/link/page/
Second, nobody is trying to inject traffic in your browser on a hotspot. Nobody. Nobody cares about your connection. There is no secret cabal of hackers sitting at every airport and starbucks waiting to steal your Facebook login. They don't give a shit. You are the tiniest small fry, and they have much easier ways of committing cybercrime that pay out much better and provide them better intel.
And yes, if I want to make sure i'm secure, I use a VPN. I assume all public browsing sessions are hijackable.
That's not right. Even if you supplied all those details in your CSR, you would not have solved this problem.
You bought the cheapest kind of certificate. Your "Organizational Unit" says "Domain Control Validated - RapidSSL". That's all it's ever going to say, no matter what you put in your CSR. Because the registrar did the bare minimum to test that you control the domain.
If you want a certificate that says anything more specific than that, you have to pay more money and provide more proof to the registrar.
If you're hosting an API that has older / embedded clients you may HAVE to support SSLv3 during a migration plan...etc
BEAST attack comes out... Use RC4.
Not long after.. RC4 is weak use GCM.
GCM isn't supported on older versions of almost everything.
Upgrade servers to 2012R2, latest versions of Linux, throw away your old phones, check out your legacy devices...
Security isn't a question with a right or wrong answer, it's a question with the best answer for the available information and the clients you have at the time. And those answers are changing daily with all the research being conducted.
If you are administering SSL enabled sites, you MUST keep track of latest security practices
Why is that? If you add a new server with different defaults, do you a) update all the other servers to the new defaults, or b) set the new server to your existing configuration.
Most server applications don't change defaults between minor versions because it leads to even worse problems. Such as users not updating because their application breaks and keeping old bugs alive.
Older clients won't even know you're there. No first page, no contact info, nothing. Just hang on page load. It might not always be desirable.
It might be a good idea to have two security levels if you're doing HSTS. One to accept every cipher under the sun to use for public pages and data, and a secure one to use to protect session cookies for logged in users.
Things to note: EV certs are much more expensive. You cannot get a cert that is both EV and a Wildcard, single domains only.
Screenshots of how the various browsers show Domain vs EV certs at:
https://www.expeditedssl.com/pages/visual-security-browser-s...
It's worth noting that the Chromium project accepts URLs for inclusion into the bundled list of sites using HSTS. (This is shared with Chrome, Firefox, and Safari.)
1) StartSSL doesn't generate it in the browser (on a secure piece of hardware IIRC), which depending on your viewpoint is good/bad.
2) No CA will allow you to get a 1024 bit cert (you're correct)
3) You should be sending the GeoTrust Global CA cert because it isn't trusted everywhere, and if it's not sent you'll get errors before you get SNI/SHA1/SSL3 errors...
4) The "(unknown)" will always occur on FireFox, unless you have an EV certificate (even OV does not show this)
You can also submit a CSR so that key generation happens on your local machine. Only the pubkey and metadata will be included in the CSR and get signed.
Maybe you trust StartSSL with your private key, maybe you don't, but in either case not giving them your private key is preferable.
https://www.digitalocean.com/community/tutorials/how-to-set-...
And you're more likely to screw up key safety yourself than for that narrow window to be exploited.
I don't think it's ridiculous.
* StartSSL.com itself doesn't use SSL, so it could be hijacked
* I get a TLS fail (ssl_error_handshake_failure_alert) on https://auth.startssl.com on Firefox 32
I'd call the first a red flag, the second a critical fail. This is the entry point to SSL on the web?
>I get a TLS fail (ssl_error_handshake_failure_alert)
That happens to me when I am on one particular provider myself. It concerns me that those providers are doing something with https connections causing them to break on their site.
Guys, they're giving you a certificate to identify yourself with. You add it in your browser. You go to their website, and you don't need a username or password to login. This certificate is much more secure than normal credentials.
Is the concept of authentication without a username+password that lost on you? It's like an SSH key except your username is embedded in it, too.
I fear for the future of internet security.
I had used StartSSL years ago and forgot about this. Not reading all the text, I expected the usual login/password prompt and hoped for a "reset password" form. Getting a browser SSL error interrupted that flow.
Now that I know, it makes more sense, but I'm going to take the position that this is a UX fail. Whether the browser's (which didn't even prompt me for a cert) or StartSSL (who could've made this clearer), I don't know.
Driving is only intended for people who have been trained and licensed to do so. Similarly, SSL certs are for people who have been trained on how to perform the tasks of a server admin, and presumably have read a 10-page ebook like How To Admin A Web Server.
Web servers in general are never supposed to be touched by the common user. They never were. Your server admin would set up a user account, and you'd dump your files in your ~user/public_html/ folder, and maybe if you were super clever you'd create a .htaccess file. The most complicated task a user ever was supposed to perform was to run "chmod 755" on the files in their /cgi-bin/ folder on their FTP site. All of this worked because an admin had to set everything up the right way and know how to do that.
So the next time you take on a technical hurdle you don't understand, I cannot stress enough how much more useful it is to either look up a good book on how to do it, or ask someone for help. It may not be as instant-gratification, but you'll get what you need done faster and understand it better.
Recommending books doesn't seem like a great idea when it comes to web security, as best practices change so often. Besides, enabling something like TLS should be easy. The more difficult it's to enable TLS, the less secure the web will be. In fact, since TLS is so difficult to set up, it's rather rarely used. If it was easier to set up, it would be more common and the web would be more secure on average.
Secondly, 'easy' is 100% subjective. To me it's incredibly easy to set up TLS. It wouldn't be easy to my grandma. But the same could be said for anything that takes technical expertise and a complex set of operations. TLS is not simple, and it will never be simple. People who understand how TLS works know this already.
1. Set up HTTPS on every site you run. No, really. That static 10 page info site for your church group? Yup, get it set up! The no-CSS blog from 1991 (before they were blogs)? Set it up! Even if you don't use WordPress (god, please tell me you are not running WordPress without SSL), and your site never lets anyone POST/PUT/DELETE/PATCH to it, remember that what people are reading is just as important. If I can hijack your site at the local coffee shop and serve malware, your readers will not be pleased. If I manage to do this in a widespread fashion, Google/Bing will blacklist your site and nobody will get to it.
2. Get a free cert! The dirty secret is that all certs are basically equal (EV and wildcard notwithstanding, though they are an entirely different matter). There are at least two places to get decent free certs: StartSSL and CloudFlare. If you want to protect something but your 10 page church website, get a cert from Namecheap for $8/year.
3. Use HTTPS-only. TFA is a great example: it's posted on a blog that can be accessed by both HTTP and HTTPS. If you leave this configuration, it's almost as bad as not having HTTPS at all. People don't type in "https://...". They go straight to "example.com" or they'll just Google "example" and click on the first link. Set up your server to redirect from port 80 straight to the canonical HTTPS version of your site.
If you are unfamiliar with how to set this up: practice. Get a Digital Ocean box for a few hours ($0.10/hour) and a free cert from StartSSL. Use a random domain name you own (you'll need a proper second level domain, but chances are you have one parked somewhere) and try setting up a site. It'll cost you as much as a single stick of gum and you'll know that much more about how to do it.
Edit:
4. Use a strong cipher suite such as this one: https://support.cloudflare.com/hc/en-us/articles/200933580-W...
5. Use nginx, at least for front-end proxy. Your life will be easier.
6. Check your setup against https://www.ssllabs.com/ssltest/analyze.html. Fix issues it highlights.
7. Don't lose your private key. Don't have it live only on the live server.
8. Use HSTS (http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) but beware that once you have it set, you cannot go back to plain HTTP. For almost everyone this should not be a problem.
If you want to be added to the Chrome HSTS preload list, which is also used by Firefox, go here: https://hstspreload.appspot.com/
1. Your browser has to support it. IE still does not support it; it is 'expected' in IE 12. Also vulnerable are people with Mac OS older than 10.9, Chrome older than 4.0.211, and Opera older than 12. Most people I know (non-techies) keep their browsers for the life of their computing device. So basically that's a gigantic pool of users who do not have HSTS support.
2. When they do finally get support, websites have to enable it explicitly. Here[1] is a sample graph of how few sites actually enabled it at the end of last year (about 2 out of every 1000 of the top 1mil sites, or 0.001905%)
3. The 'max-age' is often not set very long, meaning there's increase chance for a new attack to succeed.
4. The preload list is not scalable.
However, there's still a lot of value to adding HSTS. As for #1 and #2 and #3, HSTS is a standard that can and will be more broadly supported (and better implemented) over time probably more quickly than HTTP2 will be supported on most servers.
Personally, I'm most concerned about #4. This should be something the IETF should be working on (if they aren't already).
At the end of the day, if you've already mastered transport encryption, you may as well go forward with HSTS as well.
So staying up to date is worth it no matter what.
It is worth it. Here's why: nobody is going to target your 10-visitors-per-month site directly. You are right, most people don't care. However, there are two types of attacks that will get you in trouble. First, where I decide to sit in a coffee shop and simply hijack every HTTP request. In this case, I am not targeting you directly, but you are susceptible. Even if you don't care about that (say, you know that none of your readers are coffee drinkers/public Wi-Fi users), a much worse situation is where a network attacker is able to attach a large number of sites hosted with e.g. a specific provider. Let's say I discover that Digital Ocean has a vulnerability where I can spoof your IP. I would then MITM all HTTP traffic to all DO hosts, and if you happen to host with them you are screwed. Note that Google doesn't care whose fault it is: they blacklist first, ask questions never.
So in short, it takes very little time/money, it's a skill you should have if you run your own site, and it's warranty against bad things happening.
When I first read your scenario about hijacking my site via public wifi, it didn't strike me as very important... but after thinking about it for a few minutes, I do see the harm. Even if it's just someone screwing with my resume, I can envision situations where it could do a lot of harm.
And you do make a good point about the Google blacklist, the consequence of a Google blacklist is very bad. Even if unlikely, that alone is probably enough reason to enable HTTPS.
I've set up HTTPS several times on the small sites that I run, and probably spent about 6 hours on the process in my lifetime. Right after heartbleed came out, I switched to HTTP only. Now maybe it's time to redo the process and get it set up again...
[1] http://martinfowler.com/bliki/FrequencyReducesDifficulty.htm...
And before you start pushing out SSL on every page you have, stop using public WiFi. They will always be insecure, no matter what you do. Tether your phone or use a VPN.
I disagree. While yes a new key would be ideal, generally while you are dealing with the existing problem you will want to reach for the old key. I am not talking about situations where you misplaced the key or the server got compromised. I am talking about a situation where your current server/VPS suddenly dies and you need to spin up a new one fast. IMO, in this case wasting time on issuing/re-issuing a cert is inappropriate. On top of this, I tend to generate the certs on my laptop (I trust its RNG and physical security more than I trust the server). The key is already here. Now I can encrypt it with GPG with the full force of my 4096 bit key that only I can decrypt and store it fairly securely this way. I believe this is good enough for personal and professional sites. In the ideal case scenario, I'd also only keep these on an encrypted flash drive for even greater physical security.
I generate and store my private keys in my secure CA environment and copy them to the server. If I ever need to redeploy them or generate a new CSR (SHA-2 anyone?), I can do it without ever logging into the server.
What kinds of threat is it that you’re concerned about?
Also:
> 4. Use a strong cipher suite such as this one
Check out Mozilla's best practice. They'll give you configs for different levels of support.
> 5. Use nginx, at least for front-end proxy. Your life will be easier.
Be careful. It's tricky to configure and if you cut and paste your configuration from the Internet you will open up to arbitrary code execution.
I'm aware of issues with improperly matching php files, but not of any general configuration issues resulting in RCE.
If we had more people sitting in the anger, depression and bargaining phases of this, we might be in a better situation.
I count myself in the depression phase: the whole thing is a chaotic farce. Most websites achieve a worse security level now than 1995 export-grade SSL was thought to then. The CA system has thoroughly discredited itself through dozens of compromises and refusing to operate transparently. The TLS standard is gigantically complex, and the IETF continually fail to competently improve it to the benefit of its users.
To quote Network: `all I know is that first you've got to get mad. You've got to say, "I'm a Human Being, God damn it! My traffic has Value!"'
Why? I don't trust it for security-critical data, and I don't need it for unsecure data. The only time I ever see it being remotely useful is if I were to set up an ecommerce site, at which point you basically only need HTTPS to fend off insignificant adversaries doing payment data sniffing and for CYA. For anything else, the benefits most certainly do not outweigh the pain in the ass described in the OP.
Also, if someone manages to "hijack your site... in a widespread fashion", it probably means they've rooted your server, at which point HTTPS does nothing useful anyway, because the attacker has your privkey.
In seriousness, I outlined all the reasons why it is a good idea already. If you disagree, that is your prerogative of course, but you provide no arguments to support your point.
By all means set up HTTPS on your little site, but for the love of god don't require it.
Couple of points about the article.
Browsers verify SSL certificates for revocation (OCSP). This is an ongoing service that has a direct impact on latency - so SSL is an ongoing service very much like DNS. However, most people don't realize this.
Also you send in a CSR - certificate signing request - not CRT (which is usually short-hand for certificate).
Also it gets worse - A recent OpenSSL vulnerability would still allow SSLv3 even if it was configured with "no-ssl3": https://www.openssl.org/news/secadv_20141015.txt
This is why I built https://snitch.io - security and SSL secured sites in particular are moving targets and not "fire and forget". You really need an external process monitoring and auditing your secured site.
Have you considered somehow providing a demo of what I might see for my domain?
The screenshots show you what the app looks like. And to your point all accounts come with a free 14-day trial.
I may eventually add a free "one-off" audit - but the value in a service like Snitch is that something is constantly monitoring and alerting.
Happy to answer any other questions - you can email me anytime. This username at gmail or currylabs.com
Inconsistently and sporadically, it seems: http://news.netcraft.com/archives/2014/04/24/certificate-rev...
That article is a few months old though. Have Firefox/Chrome changed their tune due to Heartbleed?
That article cites Adam Langley - a respected engineer at Google who has worked on Chrome and parts of Go. Chrome is wildly lax with certificate revocation. Don't believe me? Browse to https://revoked.grc.com from Chrome. It is true that if someone can MITM they can block CRL/OCSP requests...but browsers (including Chrome) made the choice of 'soft-failing' and thus making it an attack vector. OCSP stapling and the proposed "OCSP Must-Staple" (https://tools.ietf.org/html/draft-hallambaker-muststaple-00) solve this problem. With all due respect to Adam, it seems a little peculiar to say revocation checks don't work when they're broken by design in the browser he worked/works on.
Chrome is the only browser that skips revocation checks for DV certificates but it still does OCSP for EV certs. Chrome has the concept of CRLsets - but these have been shown to only capture a very small portion (<1%) of revoked certificates.
Firefox has the option to hard-fail if the OCSP request isn't verified. This should be the default behavior, but the fear is that too few people understand this and would migrate to another browser if SSL secured sites randomly failed to load sometimes. Note: this is vastly preferable, in my opinion, to loading a site with a certificate of unknown status.
So my question to HN is: What is being done to simplify this process and make it a simpler, more user-friendly process? (other than what Cloudflare have done).
I 100% understand what happened to you and why you wrote this, and frankly I think someone should fix this. There's room for a great service here in my opinion
If you don't have the time to spend properly administrating a system, don't do it; use a hosted platform so that someone else (who knows what they're doing) does it for you.
- Android is super strict with certificates...make sure you properly order your server and intermediates
- Check your site on: https://www.ssllabs.com/ssltest/. This helped me solve a lot of issues
This the only nitpick I have with this otherwise fine rant. Everything is broken, rejoice!