SSL Still Mostly Misunderstood | Hacker News Reader

SSL Still Mostly Misunderstood

darkreading.com

12 pointsedw51910 comments

It's not just misunderstood by users, it's also misunderstood by companies. One of my client's competitors has been in business for over 4 years. They do over $1M a year in online sales with thousands of customers.

And you guessed it... no SSL certificate.

Shocks me that either nobody has complained to them or they haven't listened.

SSL documentation in most major projects still needs a lot of polishing.

I also think there needs to be a push to separate the encryption and remote server verification parts of SSL/TLS. I'd love to encrypt all communication with the sites I run, but am completely uninterested in coughing up cash for an SSL cert.

Then generate your own certs and self-sign.

As I understand it, self-signed certs leave you open to man-in-the-middle attacks.

http://news.ycombinator.com/item?id=277284

Still pops up warnings for users in browsers.

As they should. Since there is no way to verify the remote server then the connection is vulnerable to man-in-the-middle attacks. In that situation an attacker can simply pretend to be the server and decrypt your traffic.

Heck, I think most programmers misunderstand SSL. The other day, a senior developer I work with asked me which HTTP header the SSL certificate is sent through...

The article would be better if it provided a link to the survey as well as resources about SSL (for users and developers).

I've configured https servers (with a cert from Verisign and self-signed) and thought that communication to-and-from those servers was encrypted, and thus secure. Now I'm wondering what I've misunderstood.

Test your SSL site here: https://www.ssllabs.com/ssldb/index.html

It annoys me to no end when the SSL/TLS connection is hidden behind a click. Joe user is asked -- taught -- to trust an http page without knowing what protocol the resulting request will use nor whether the recipient is verified.

I set the browser to notify when transitioning from https to http. Then I try to force a site to give me an https connection before I start entering sensitive data. If the browser pops a protocol transition warning, I back out.

It also annoys me when an https delivered page in turn pulls in http content. This breaks the security of the entire rendered page. Having the user check for the https protocol in the address bar is not sufficient.

It seems to me that the basic concepts involved are not that difficult (leaving out the math). Don't start communicating until you know the "channel" is secure and the other endpoint is verified. Verification is accomplished through a chain of trust. Pages are composed of multiple pieces. If any piece/participant in the channel comes from an unsecured or unverified source, you must treat the channel as compromised.

But no browser presents them in a clear and meaningful fashion, with enough context to describe plainly to the average user what is going on.

Reply on news.ycombinator.com