

SSL Still Mostly Misunderstood  - edw519
http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=220301548

======
keltex
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.

------
a2tech
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.

~~~
gthank
Then generate your own certs and self-sign.

~~~
axod
Still pops up warnings for users in browsers.

~~~
chowmeined
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.

------
j_baker
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...

------
thirdstation
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.

~~~
thaidn
Test your SSL site here: <https://www.ssllabs.com/ssldb/index.html>

------
pasbesoin
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.

