Punchline: Dreamhost is now selling 1-year browser-trusted SSL certs for $15, but the domain has to be hosted @ dreamhost, and you also need a unique IP ($3.95/month).
Comments under the blog posting imply the certs contain CN=www.domain.com, with Subject-Alt-Name=domain.com to get around the ever annoying "www." issue there, but I haven't seen one for myself to verify.
Actually you don't need a unique IP--You can have a bunch hosted on one IP, as long as they all have unique port numbers (I host 4 or 5 ssl domains on my server). I usually forward the non-ssl site to the appropriate port so no one has to memorize the ugly number.
Not particularly a technical limitation, but a practical one:
Unfortunately, if your web site is intended to reach the masses, many of whom sit behind restrictive firewalls that only proxy 80 and 443 for web traffic, you need to be on ports 80 and 443.
Well, right now it's like this (maybe they'll change it?):
"You can add your certificate from our panel’s Manage Domain area."
And that panel won't let you "add certificate" until you get yourself the unique IP address for about $50/year; nevermind the strange feeling of setting up a domain through the panel which you never intend on hosting there. They still setup all the server space and resources, but you (the certificate buyer) just never gets around to pointing DNS at ns1.dreamhost.com...
I think what he means by "You can use them with us or any other web host..." is that, should you choose to move to a different web hosting company, Dreamhost will make it easy for you to take the certificate with you.
SSL/TLS does not work without certificates. In the absence of a "tie breaker" for someone else's fake handshake data, the encryption it employs on the link provides no more security than does LZ compression. And I'm supposed to buy certs from these people?
Should CA processes be reformed? May-be so. I'd start with not allowing people like Dreamhost to sell them. But that has nothing to do with how the browsers enforce the SSL protocol.
Oh, sorry, I read this post like 10 times looking for something to rant about, and nothing about it "stuck", so I didn't recognize it as a direct question. Shows you how I think.
This is one example of the tens of different side channels that exist on modern CPU architecture when you can run code alongside crypto on the same microarchitecture.
How serious are these problems long term? Nobody knows. The full microarchitecture of an Intel or AMD processor isn't documented.
He's right the whole thing is a scam, but his solution is not correct. What needs to happen is the domain owner should be issued a wildcard cert for their domain when they purchase the domain. The public key goes in the DNS and is itself signed by the registry (this prevents DNS spoofers from injecting valid certs).
So if I bought example.com I'd get a cert for * .example.com and its public key would sit in my dns somewhere signed by the master .com cert.
This would be more secure than what we have now and get rid of all the overpriced ssl resellers (really, you're charging me $100 a year for your thin wrapper around openssl?).
13 comments
[ 2.8 ms ] story [ 35.1 ms ] threadComments under the blog posting imply the certs contain CN=www.domain.com, with Subject-Alt-Name=domain.com to get around the ever annoying "www." issue there, but I haven't seen one for myself to verify.
No wildcard certs at this price level, sadly.
From the post:
You do however need a unique IP regardless of where you're hosting it.Unfortunately, if your web site is intended to reach the masses, many of whom sit behind restrictive firewalls that only proxy 80 and 443 for web traffic, you need to be on ports 80 and 443.
"You can add your certificate from our panel’s Manage Domain area."
And that panel won't let you "add certificate" until you get yourself the unique IP address for about $50/year; nevermind the strange feeling of setting up a domain through the panel which you never intend on hosting there. They still setup all the server space and resources, but you (the certificate buyer) just never gets around to pointing DNS at ns1.dreamhost.com...
I think what he means by "You can use them with us or any other web host..." is that, should you choose to move to a different web hosting company, Dreamhost will make it easy for you to take the certificate with you.
Preach it, homey!
I've been ranting about this same thing for years. Why is this fundamentally broken in so many browsers?
See:
http://news.ycombinator.com/item?id=277284
Should CA processes be reformed? May-be so. I'd start with not allowing people like Dreamhost to sell them. But that has nothing to do with how the browsers enforce the SSL protocol.
Like probably 5,000 other people have SSH accounts into the same dreamhost server where http://juliusdavies.ca/ lives!
:-p
(This is not in anyway a response to tptacek's comment. Just a tangent.)
What do I think? Bad. I have a reason:
http://www.matasano.com/log/460/modern-cpu-architecture-thre...
This is one example of the tens of different side channels that exist on modern CPU architecture when you can run code alongside crypto on the same microarchitecture.
How serious are these problems long term? Nobody knows. The full microarchitecture of an Intel or AMD processor isn't documented.
So if I bought example.com I'd get a cert for * .example.com and its public key would sit in my dns somewhere signed by the master .com cert.
This would be more secure than what we have now and get rid of all the overpriced ssl resellers (really, you're charging me $100 a year for your thin wrapper around openssl?).
EDIT: I think there is an RFC for this already: http://tools.ietf.org/html/rfc4398
http://www.matasano.com/log/756/a-case-against-dnssec-count-...
http://www.matasano.com/log/772/a-case-against-dnssec-count-...
I stopped reading right about there.