The process of adding SSL to a website could be 100% automated.
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.
A company could probably set up an API to allow people to submit/validate CSR requests via pre-validated profile, but at install time? Nah. There's a lot of configuration that needs to happen after you install a web server anyway.
And anyway, most websites don't need SSL. Anyone who tells you different is probably wearing an aluminum foil fashion accessory.
> 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 ;-)
> And anyway, most websites don't need SSL. Anyone who tells you different is probably wearing an aluminum foil fashion accessory.
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.
Mitm is still pretty trivial to perform from hotspots, even for supposedly-https websites. There's a dozen ways I can inject traffic into your browser, whether on the initial connection to the site you want, or in one of the many non-https connections from 3rd party content loaded into practically every website on the internet. This isn't even taking into account the vast number of attacks on https clients and protocols.
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.
I'm not sure that this is a 100% correct proposal, but it definitely seems like the right direction. To the author's point -- setting up transport encryption should be painless, not the awful experience it is today.
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.