71–80 of 264 posts
I was under the impression the private key for authentication to the StartSSL site was generated in the browser with the keygen tag, not on the server…
It is. The website is wrong. Assuming your browser implements it securely, it's no less safe than generating it client-side with openssl.
Earlier quoted context omitted.
Almost 1 in 5 people on the web are still running Windows XP. No version of Internet Explorer on XP supports SNI. Neither does Safari on XP, the browser in Android 2.x, the BlackBerry browser or Opera Mobile before 10.1. It may be a minority of users, but it's not just "people who are still running IE6". Pretty much everyone would love to use SNI; site owners wouldn't have to pay for extra IPs, hosting companies woul…
I appreciate your detailed response! I should not have been so dismissive of those users. Still, I maintain that the "extra cost for a dedicated IP" is a poor excuse for not implementing SSL.
If browsers got fixed to not freak out on self-signed certificates, this wouldn't even be an issue, HTTPS could be a default.
But what they ought to do is to accept the self-signed certificate, show something other than the usual lock icon but do the encryption anyway, and then freak out if the certificate changes before it expires.
Using HTTPS everywhere doesn't really help much. It doesn't help at all if the surveillers either have your cert or access to decrypted traffic inside the firewall. Any PII being sent over the wire should most definitely be encrypted, but encrypting my access to a news site isn't really hiding anything. The requested URL still need to be unencrypted, you'd just be encrypting content that is already availble unencrypt…
> The requested URL still need to be unencrypted The SSL connection is set up before the HTTP request is sent; that's why the dedicated IP per domain is required, since the domain (Host header) is part of the request as well. The URL you're accessing is not sent in the clear.
Earlier quoted context omitted.
Any IExplorer on Windows XP, Safari on Windows XP, Android 2.x, Blackberry, Symbian, Java before 1.7, Windows Mobile up to 6.5 ... the list is quite significant. Depending on your target, you can easily talk about 25% of the traffic.
Safari on Windows isn't even supported anymore. Who uses it?
In the switch to https everywhere, we have barely started. For every HN and wikipedia with https there are 20 websites without (and whether the ones that do https do really secure https is yet another question). Somebody should go through the top 10k websites and make a list, then repeat every few months.
Earlier quoted context omitted.
It is. The website is wrong. Assuming your browser implements it securely, it's no less safe than generating it client-side with openssl.
Oh, whoops. Can you recommend how I should change the text? Anything you can link to to show me what you mean?
The site authentication private key and the S/MIME private key, however, are always generated in the user's browser.
From my experience (on OS X), if you want maximum flexibility for selecting your S/MIME key size, the browser you should use is the last pre-Chromium release of Opera. It allowed me to select 4096-bit RSA private key and SHA-256 hash algorithm, whereas Firefox, Safari, and Chrome have no option greater than 2048 bits.
Oh, the sweet irony - > SSL’s not perfect, but we need to make surveillance as expensive as possible immediately followed by - > And hey, bonus: more complete referrer information in Google Analytics Make up your mind already. Are you against the surveillance or for it? You can't really sit with one ass on two chairs. -- (edit) Point being is that if you are pulling the anti-surveillance card, then you shouldn't real…
I agree, though, it is kind of silly, knowing that Google has been complying with large numbers of FISA requests.
If browsers got fixed to not freak out on self-signed certificates, this wouldn't even be an issue, HTTPS could be a default.