241–250 of 264 posts
In testing, we found that DigiCert was 50-100ms faster on queries than our existing GoDaddy certificate, based on the location of their CA hosts.
The improved response time resulted in a 15% increase in traffic on our API.
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's been studied and pointed out that a green-bar does nothing to conversions and sales. I'm not debating this point, but if you have some citations for this assertion, I'd love to read them. I've always heard and read otherwise. I just completed a multiple-month-long process of converting a dynamic-domain application to support SSL-friendly URIs and implementing SSL on it's web servers based entirely on the concept…
Considering Amazon.com doesn't bother with an EV cert, I'd guess they don't affect conversions in any sort of positive manner.
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…
But they're all in China, so if that isn't your market, then don't worry about it.
(Source: http://developer.android.com/about/dashboards/index.html)
Earlier quoted context omitted.
Instead of using nginx or a Web server for SSL, you might consider using something like stunnel for SSL termination as recommended by 'cperciva: "...for security reasons, I prefer to keep SSL termination separate from HTTP serving" ( http://colin.percival.usesthis.com , http://www.daemonology.net/blog/2009-09-28-securing-https.ht... ). In his 2010 talk "Everything you need to know about cryptography in 1 hour" ( http…
Deploying SSL partially is very dangerous, because then you have to be _very_ careful that the session ID is not compromised. I'd go as far as to say that it's virtually impossible to do that securely (for the average web site, built by more than one person who are not security experts, maintained under pressure over a period of years, and so on). Someone else here mentioned SSL stripping, which is another problem, w…
If browsers got fixed to not freak out on self-signed certificates, this wouldn't even be an issue, HTTPS could be a default.
Sort of. You actually do need to know when a certificate is self-signed because it means the connection isn't authenticated even if it's encrypted . 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.
HTTPS with self-signed certificates is better than moving plaintext over the wire, in the same way PGP is better than moving plaintext over the wire. It doesn't matter that you don't have a "trusted" peer to tell you this PGP signer is who it says it is. As long as you can trust you acquired his key in a secure way (e.g., out-of-band), it's better than the alternative.
Plus, MITM concerns over self-signed certs are moot. This vulnerability exists at the DNS level anyway.
When it's harder to get SSL working than to install debian stable on a machine, I'd say SSL is too hard.
This is mostly the fault of the SSL certificate providers, which vary in complexity between the obnoxious GoDaddy and even more obtuse and impossible to deal with. Compounding this, the configuration file formats for each web server platform vary wildly, selecting the correct format and installing it properly can be tricky. Making matters worse, it's very easy to set up something that looks like it's working, but is…
Earlier quoted context omitted.
Deploying SSL partially is very dangerous, because then you have to be _very_ careful that the session ID is not compromised. I'd go as far as to say that it's virtually impossible to do that securely (for the average web site, built by more than one person who are not security experts, maintained under pressure over a period of years, and so on). Someone else here mentioned SSL stripping, which is another problem, w…
That's very convincing. What then is the advantage of only selectively using SSL, and why are some people recommending it?
In my experience, most people are recommending partial SSL because they're not aware of the security issues. For example, many developers "know" that you're supposed to use SSL only to protect login credentials.
Do people trust StartCom? Just curious ... I always wondered why you have all these very expensive cert providers who charge a lot for SSL certs, and then this mysterious company with ties to Israel is handing them out for free? I know it's pure paranoia, but this would seem to be an excellent way to compromise a lot of SSL traffic if you were into that, and the Israelis are pretty famous for all kinds of spying acti…
And to further your paranoia, the NSA and Israeli intelligence orgs have form on doing each others dirty work.
But what that really points out is the brokenness at the heart of the PKI system as it's currently implemented.
When was the last time you audited your browsers trust store?
Earlier quoted context omitted.
Instead of using nginx or a Web server for SSL, you might consider using something like stunnel for SSL termination as recommended by 'cperciva: "...for security reasons, I prefer to keep SSL termination separate from HTTP serving" ( http://colin.percival.usesthis.com , http://www.daemonology.net/blog/2009-09-28-securing-https.ht... ). In his 2010 talk "Everything you need to know about cryptography in 1 hour" ( http…
Deploying SSL partially is very dangerous, because then you have to be _very_ careful that the session ID is not compromised. I'd go as far as to say that it's virtually impossible to do that securely (for the average web site, built by more than one person who are not security experts, maintained under pressure over a period of years, and so on). Someone else here mentioned SSL stripping, which is another problem, w…
And while HSTS helps protect against sslstrip, you're still vulnerable to MITM attacks due to issues with the CA system.
See moxie's 2011 talk "SSL and the Future of Authenticity" ( http://www.youtube.com/watch?v=Z7Wl2FW2TcA)