I'm using one of THE worst browsers out, called the Blackberry Browser. Yet HN is one of the few websites that renders just as well as my updated ubuntu machine running newest firefox.
I tried to help back when DDG started out here. DDG was doing 'funky business' on my BB curve 8530, which made it unusable. I offered assistance with making it BB friendly. He asked for screenshots.....(drumroll)
Do you know how hard it is to make screenshots of a BB device? GAH. You need it plugged in a Windows computer (sorry, no Mac or Linux) and have a package on your BB, and run a program with the usb cable connected, and the screenshot goes to the computer. WTF?
On a I(Phone|Pod Touch), I press the sleep button and then tap the home button. CHING
"Completely aside"... Im ditching my BB when my contract ends :)
HTTPS shouldn't be much of a performance issue to an all-text site such as HN.
I run a HN-like site in Hebrew, and I recently made the switch myself (https://bitorama.com). Traffic there is a lot lower than in HN, but so far I haven't noticed any latency issues.
The change went smoothly with nginx, though I'm not certain this data point is relevant to HN.
I don't know that it's really ideal to try to force all normal browsing activity to HTTPS. If a person is concerned about pedestrian, non-identifying data, like reading HN, then he should take it upon himself to set up a VPN or some other mechanism to encrypt his data. Why do we want to establish a standard of default HTTPS?
Well HTTPS wouldn't have prevented that. In the AOL case the company at the other end of the connection released the information.
I guess someone in a sensitive position (e.g. someone with access to the routers at a major ISP) could intercept a every bit of traffic and produce a similar result but it doesn't seem likely and there's a flip side to this argument which is it puts a financial strain on the companies themselves.
Wikipedia, for instance, surely wouldn't have the processing power to switch all its connections to https. So they'd have to significantly upgrade their infrastructure at an equally significant cost.
HTTPS may not be able to prevent companies releasing information, but the article shows the similar kind of information that eavesdropping could yield. You say Wikipedia wouldn't have the processing power to switch all connections to https, but I see that eavesdroppers wouldn't have the processing power to decrypt all connections to https.
I would point to Iran and similar countries happy that users don't use encrypted connections but I found too many replies of "It won't happen to us [in this peaceful country]."
Again, HTTPS isn't the only mechanism by which one can encrypt his/her communications. Persons in Iran should use a VPN or something like Tor or I2P. I don't think there's a reason to force Wikipedia to use HTTPS by default.
One thing I'm impressed with is sites that allow people to embed images from anywhere but still don't have mixed content. The way GitHub and Convore do this is by making images from an http-only domain available on an https domain. If you try pasting an image from GitHub pages (GitHub pages is HTTP only) and you inspect an image on Convore I think it will point to an https address on Rackspace Cloud Files.
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.
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.
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.
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.
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.
"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?)
They should redesign the header so that the site title looks like an actual header instead of a large text box. I spent a while trying to click on it to enter in my own site to check.
29 comments
[ 2.3 ms ] story [ 41.5 ms ] threadThen there's this comment: 'pg doesn't care about security.'
I'm using one of THE worst browsers out, called the Blackberry Browser. Yet HN is one of the few websites that renders just as well as my updated ubuntu machine running newest firefox.
I tried to help back when DDG started out here. DDG was doing 'funky business' on my BB curve 8530, which made it unusable. I offered assistance with making it BB friendly. He asked for screenshots.....(drumroll)
Do you know how hard it is to make screenshots of a BB device? GAH. You need it plugged in a Windows computer (sorry, no Mac or Linux) and have a package on your BB, and run a program with the usb cable connected, and the screenshot goes to the computer. WTF?
On a I(Phone|Pod Touch), I press the sleep button and then tap the home button. CHING
"Completely aside"... Im ditching my BB when my contract ends :)
The change went smoothly with nginx, though I'm not certain this data point is relevant to HN.
It's a pretty clunky interface.
I guess someone in a sensitive position (e.g. someone with access to the routers at a major ISP) could intercept a every bit of traffic and produce a similar result but it doesn't seem likely and there's a flip side to this argument which is it puts a financial strain on the companies themselves.
Wikipedia, for instance, surely wouldn't have the processing power to switch all its connections to https. So they'd have to significantly upgrade their infrastructure at an equally significant cost.
I would point to Iran and similar countries happy that users don't use encrypted connections but I found too many replies of "It won't happen to us [in this peaceful country]."
https://github.com/benatkin/pure-ssl
One thing I'm impressed with is sites that allow people to embed images from anywhere but still don't have mixed content. The way GitHub and Convore do this is by making images from an http-only domain available on an https domain. If you try pasting an image from GitHub pages (GitHub pages is HTTP only) and you inspect an image on Convore I think it will point to an https address on Rackspace Cloud Files.
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.
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.
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.
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?)