Attacks/Breaches
7/9/2014
11:15 AM
Sara Peters
Sara Peters
Slideshows
Connect Directly
Twitter
RSS
E-Mail
50%
50%

6 Things That Stink About SSL

Users might not care to trust the very mechanism that's supposed to provide online trust.
Previous
1 of 7
Next

When Heartbleed came along, some people in the security community were alarmed. Many others, however, weren't terribly concerned, because, after all, SSL was never perfect and we shouldn't be surprised anyway.

Perfect or not, we still use it... a lot.

SSL (Secure Sockets Layer) is one of the most important components of Internet security, and the most significant online trust mechanism, essential to online shopping, banking, and socializing.

Yet, the very mechanism we rely on to provide trust is, itself, untrustworthy. Here are a few reasons why... 

 

 

Sara Peters is Senior Editor at Dark Reading and formerly the editor-in-chief of Enterprise Efficiency. Prior that she was senior editor for the Computer Security Institute, writing and speaking about virtualization, identity management, cybersecurity law, and a myriad ... View Full Bio

Previous
1 of 7
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
inanimatt
50%
50%
inanimatt,
User Rank: Apprentice
7/17/2014 | 5:37:40 AM
5 things that stink about SSL
Mostly great points, but there's one weirdly silly one: "#2 bad guys use it too". How would you propose to create a morally selective transport encryption protocol? :)
andre.boysen
0%
100%
andre.boysen,
User Rank: Author
7/16/2014 | 10:06:11 PM
Meta conclusion - its dumb to require smart users for security to be effective
Expecting users to understand what risks are present and how to effectively deal with them is bad design. The system designers are in a better place to know what risks are present - rather than admonish users for bad clicking behaviour the focus should be on system designers providing users the option to click through to bad destinations.
sevis
50%
50%
sevis,
User Rank: Apprentice
7/16/2014 | 12:50:40 AM
Great article
This is easily the most level-headed and most accurate description of "the SSL problem" that I have read. So refreshing to read something by someone who obviously actually understands the issue, not some journo with a word processor and the uncanny ability to make sentences with words they do not know,
shortlink
100%
0%
shortlink,
User Rank: Apprentice
7/15/2014 | 11:05:49 AM
Re: Poor TLS
There is no good management of the certificates and who knows how so many trusted CAs or certs have made it into the certificate store. If you try and remove them all and work you way up to approving the root CAs or certs it doesn't work. Most of the time you get an error not the option to trust a root cert.

Given the government snooping and hackers able to compromise key organizations like RSA, the assumption that all those certs are valid is difficult to prove. Do I really need the root CA for a third world country in my cert store?

 

shortlink
theb0x
50%
50%
theb0x,
User Rank: Moderator
7/14/2014 | 10:44:27 AM
Re: Poor TLS
I would like to see further developement and use of DTLS-SRTP.
kmccarthyma
100%
0%
kmccarthyma,
User Rank: Strategist
7/11/2014 | 5:12:01 AM
Re: Poor TLS
Throwing the baby out with the bath water is never a good idea., especially given the massive market penetration that TLS has. True, the likes of Henry Ford proved that turning the tide is feasible...

Information Security must always involve continual assessment with associated improvements. Every weakness can be tackled individually: if the algorithms become compromised then one can attempt to ensure that others are uniformly substituted (in principle at least). DES -> 3-DES -> AES. RSA 1024 -> RSA 2048+

It does however surprise me that CAs and their associated RAs do not tighten up their processes with regard to individual sites:

i) should the CAs consider undertaking a policing function -  if their certificates are used by sites that are regularly breached or if weak algorithms are permitted then the CA could more readily consider intervening and issue a revocation at the single site. That said they are commercial organisations and their customers can readily take their business elsewhere.

ii) their RA issuance requirements can be subverted

Should user education be compulsory for Net usage in an attempt to avoid account/sales compromise when TLS is used - just as taking a driving test is required in an attempt to avoid crashes? Unfortunately whilst I would argue 'yes' to both, it is clearly not going to happen, especially whilst the financial organisations provide coverages for losses.

======================================================================

For whatever secure channel is developed it will always come down to:
1) Confidentiality - heavily dependent on the selected cryptographic algorithm (whether the NSA has insight into it or not)
2) Integrity - heavilydependent on the selected cryptographic algorithm (again whether GCHQ has insight into it or not).
3) Server Authentication - dependent on the CA's (or more strictly the RA's) attestation criteria (yes there are indeed obvious weaknesses for those who have been through the issuance process many times). Whether certificate issuance has been actively been misused [1]. Whether the WWW server itself had been breached is down to the site build, maintenance and monitoring; the DNS configuration etc.
4) Client authentication - multi-factor, biometric, man-in-the-browser attacks.
5) Implementation [2] - there are numerous implementations of every secure channel that has ever been designed, what software is bug free, whether open source or developed by a global?
6) Usage/users  - whatever secure channel that is developed can be used by whoever has access to the software - redesigning the channel would not change this. If users fail to act on warnings or install software that assists in enforcing this then it falls back on user education to attempt to provide the necessary skills.
[1] https://technet.microsoft.com/en-us/library/security/2982792.aspx
[2] http://thehackernews.com/2014/04/heartbleed-bug-explained-10-most.html

Sara Peters
100%
0%
Sara Peters,
User Rank: Author
7/10/2014 | 6:20:49 PM
Re: Poor TLS
@Nazish  Glad I could help! Out of curiosity, what was your colleague's argument? Did he/she think that expired certificates were fine?
Sara Peters
100%
0%
Sara Peters,
User Rank: Author
7/10/2014 | 6:18:24 PM
Re: Poor TLS
@kmccarthy   "Strictly they are all '6 Things That Stink About THE USES AND USERS of SSL'"  You're not wrong. And you were right before too -- I'm not about to write a new protocol myself!

What do you think? Is SSL completely fine and we just need to do a better job of implementing it? Or do we need something new -- either in addition to or in lieu of SSL?

 

 

 
Kelly Jackson Higgins
100%
0%
Kelly Jackson Higgins,
User Rank: Strategist
7/10/2014 | 4:10:48 PM
Re: Poor TLS
Sometimes, the state of SSL deployment is sad and worrisome. So a little light-hearted yet informational reminder is very useful. Great stuff, Sara!
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
7/10/2014 | 12:42:24 PM
humor is always a great teacher
Very amusing way to convey an important message! niecely done Sara. This would be a great user education tool!
Page 1 / 2   >   >>
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7407
Published: 2014-10-22
Cross-site request forgery (CSRF) vulnerability in the MRBS module for Drupal allows remote attackers to hijack the authentication of unspecified victims via unknown vectors.

CVE-2014-3675
Published: 2014-10-22
Shim allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted DHCPv6 packet.

CVE-2014-3676
Published: 2014-10-22
Heap-based buffer overflow in Shim allows remote attackers to execute arbitrary code via a crafted IPv6 address, related to the "tftp:// DHCPv6 boot option."

CVE-2014-3677
Published: 2014-10-22
Unspecified vulnerability in Shim might allow attackers to execute arbitrary code via a crafted MOK list, which triggers memory corruption.

CVE-2014-4448
Published: 2014-10-22
House Arrest in Apple iOS before 8.1 relies on the hardware UID for its encryption key, which makes it easier for physically proximate attackers to obtain sensitive information from a Documents directory by obtaining this UID.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.