4 ms·

The barrier to ubiquitous encryption on the web is the requirement that everyone purchase an overprice certificate. What we need is HTTPC, which would be SSL w

by api 16y ago

The barrier to ubiquitous encryption on the web is the requirement that everyone purchase an overprice certificate. What we need is HTTPC, which would be SSL without verification. It would not show up as verified like HTTPS-- no green bar, etc. It would look just like HTTP, except with encryption.

RyanGWU82 16y ago
You can get free standard SSL certificates from StartSSL - https://www.startssl.com https://www.startssl.com They also offer extended validation and other paid options. I use them for wildcard certificates, which are normally at least $200 each. I've created nine wildcard certs since January 1, for a total cost of $50.
- premchai21 16y ago
  An interesting aspect of StartSSL is that they require physical residence addresses for natural persons even for their low-verification certificates. This seems a bit strong for “validate that the site that I'm talking to is ‘legitimately’ bound to name X”; this is the reason I've been on the fence about going that route.
- hrasm 16y ago
  Note: The free SSL certificates are for non-commerical purposes only.
mrkurt 16y ago
Encryption without verification doesn't really get you much. It prevents firesheep, but doesn't stop me from sitting at Starbucks with my laptop broadcasting an "attwifi" SSID and acting as a proxy.
hrasm 16y ago
I paid for my domain name and got an SSL certification along with that purchase. In all, it was USD 15. IMO, that is not overpriced at all.
keeperofdakeys 16y ago
We already do, self signed certificates, it is just that browsers give an untrusted certificate warning. When you really think about it, self-signed certificates are kind of misleading. The whole point of encryption is that nobody else can read your data, the problem is this kind of certificate has no hope of stopping man-in-the-middle attacks. This is because the intruder could give you a fake certificate, but you have no way of knowing whether it is actually the real one. You have to ask, is it REALLY okay to use encryption if I may not trust the certificate. SSH also has these kinds of problems, asking the user if they REALLY trust the unknown public key they are offered, but caching known ones in a file (web browsers also do this though). With a modification we could get a better system though. If we have a trusted third-party that has a CA certified certificate (we know we can trust them), we could ask them to contact the server on our behalf and forward us the certificate. This way we know that the certificate for the server is authentic. If we then cache the certificate we will not need to ask the third-party again. The problem with this system is would there actually be anyone who would want to run it, we would need to absolutely trust them, and there isn't really any monetary gain in it (for a service this size, you would need a company to back it, in all honesty), maybe some CA would do it. So you can already use self-signed certificates, it is just users are given a large red screen with a tiny "trust it" button.
- jerf 16y ago
  "When you really think about it, self-signed certificates are kind of misleading." Given the ease of obtaining a root certificate, I'd say nowadays they're a great deal less deceptive than some CA-signed certificates. Visiting a site that has a self-signed cert doesn't prove your connection is safe. Visiting a site that has a CA-signed cert doesn't prove your connection is safe. What's the point of this exercise again? I'm not sure at all what your second paragraph gives us. We don't need a fourth party to mediate the certification the third party gives us. The whole process of cert signing is a certification from a third party. That part actually works; the problem is that browsers accept signatures from organizations they should not, and the meta-problem is that there really isn't a solution to that problem. (What cert organization is secure against their local law enforcement?)

by api 16y ago

RyanGWU82 16y ago

You can get free standard SSL certificates from StartSSL - https://www.startssl.com https://www.startssl.com They also offer extended validation and other paid options. I use them for wildcard certificates, which are normally at least $200 each. I've created nine wildcard certs since January 1, for a total cost of $50.

premchai21 16y ago
An interesting aspect of StartSSL is that they require physical residence addresses for natural persons even for their low-verification certificates. This seems a bit strong for “validate that the site that I'm talking to is ‘legitimately’ bound to name X”; this is the reason I've been on the fence about going that route.
hrasm 16y ago
Note: The free SSL certificates are for non-commerical purposes only.

mrkurt 16y ago

Encryption without verification doesn't really get you much. It prevents firesheep, but doesn't stop me from sitting at Starbucks with my laptop broadcasting an "attwifi" SSID and acting as a proxy.

hrasm 16y ago

I paid for my domain name and got an SSL certification along with that purchase. In all, it was USD 15. IMO, that is not overpriced at all.

keeperofdakeys 16y ago

We already do, self signed certificates, it is just that browsers give an untrusted certificate warning. When you really think about it, self-signed certificates are kind of misleading. The whole point of encryption is that nobody else can read your data, the problem is this kind of certificate has no hope of stopping man-in-the-middle attacks. This is because the intruder could give you a fake certificate, but you have no way of knowing whether it is actually the real one. You have to ask, is it REALLY okay to use encryption if I may not trust the certificate. SSH also has these kinds of problems, asking the user if they REALLY trust the unknown public key they are offered, but caching known ones in a file (web browsers also do this though). With a modification we could get a better system though. If we have a trusted third-party that has a CA certified certificate (we know we can trust them), we could ask them to contact the server on our behalf and forward us the certificate. This way we know that the certificate for the server is authentic. If we then cache the certificate we will not need to ask the third-party again. The problem with this system is would there actually be anyone who would want to run it, we would need to absolutely trust them, and there isn't really any monetary gain in it (for a service this size, you would need a company to back it, in all honesty), maybe some CA would do it. So you can already use self-signed certificates, it is just users are given a large red screen with a tiny "trust it" button.

jerf 16y ago
"When you really think about it, self-signed certificates are kind of misleading." Given the ease of obtaining a root certificate, I'd say nowadays they're a great deal less deceptive than some CA-signed certificates. Visiting a site that has a self-signed cert doesn't prove your connection is safe. Visiting a site that has a CA-signed cert doesn't prove your connection is safe. What's the point of this exercise again? I'm not sure at all what your second paragraph gives us. We don't need a fourth party to mediate the certification the third party gives us. The whole process of cert signing is a certification from a third party. That part actually works; the problem is that browsers accept signatures from organizations they should not, and the meta-problem is that there really isn't a solution to that problem. (What cert organization is secure against their local law enforcement?)