Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
The Internet Security

Black Hat Presentation Highlights SSL Encryption Flaws 152

nk497 writes "Hackers at the Black Hat conference have shown that SSL encryption isn't as secure as online businesses would like us to think. Independent hacker Moxie Marlinspike showed off several techniques to fool the tech behind the little padlock on your screen. He claimed that by using a real world attack on several secure websites such as PayPal, Gmail, Ticketmaster and Facebook, he garnered 117 email accounts, 16 credit card numbers, seven PayPal logins and 300 other miscellaneous secure logins."
This discussion has been archived. No new comments can be posted.

Black Hat Presentation Highlights SSL Encryption Flaws

Comments Filter:
  • Re:Oh god (Score:4, Informative)

    by Lord Ender ( 156273 ) on Thursday February 19, 2009 @12:20PM (#26917755) Homepage

    OK: "Some implementations of SSL encryption are flawed. These can be fixed. SSL encryption itself is not flawed."

  • The same guy. (Score:2, Informative)

    by Anonymous Coward on Thursday February 19, 2009 @12:45PM (#26918071)

    This is the same guy who published the infamous basic constraints IE vulnerability [thoughtcrime.org] a few years ago. His website and the software is www.thoughtcrime.org [thoughtcrime.org]

  • by AusIV ( 950840 ) on Thursday February 19, 2009 @12:58PM (#26918269)
    The problem is that a MITM can modify that 301 redirect from https://secure.example.com/ [example.com] to http://secure.example.com/ [example.com] Since they're in the middle of the transaction, they capture your packets and encrypt them before forwarding them on to https://secure.example.com./ [secure.example.com] The only indicator that something is amiss is the lack of an 's' in the protocol, which lots of people won't notice.

    Alternatively, he might redirect from https://secure.example.com/ [example.com] to https://secure.example.com/.ijj.cn [example.com], except that the slashes and dots in the last example are unicode characters that look like slashes and dots, so they don't register with the browser in the same way. He gets a legit cert to *.ijj.cn, then logs everything and forwards your responses to the address before .ijj.cn. For long URLS (which many secure logins have), the trailing .ijj.cn ends up past the end of your URL bar, and you don't notice.

    After seeing Moxie's presentation, I'll be double checking every URL that needs to be secure to verify the 'https' protocol, and doesn't have any unusual endings. For things like the bank, I'll probably just bookmark the https version and never request the http version.

  • by laoc00n ( 933461 ) on Thursday February 19, 2009 @04:13PM (#26921153)
    This is actually not a problem with SSL. It's a basic flaw in the design of X.509 (the certification spec that SSL uses), and has been known and talked about from the beginning. You have critical policy information (e.g., the "basic constraints" certificate extension) being expressed in a credential, but the consumer of that credential may or may not interpret the information correctly. The lesson here (which gives the lie to all the PKI hype) is that you cannot separate certification policy from application policy.
  • by daemonburrito ( 1026186 ) on Thursday February 19, 2009 @08:55PM (#26924141) Journal

    It's not a conspiracy theory. It appears that a lot of businesses have concluded that occasionally eating the loss on a fraudulent transaction is cheaper than fixing problems.

    Maybe it should be "...isn't as secure as online businesses would like it to be."

    If they "would like it to be" secure all they would have to do is spend more money on their infrastructure to encrypt everything. So, while it's not a "conspiracy", users who trust sites like paypal or their bank should be upset that these businesses have decided that security is too expensive. Users should be upset that big sites that handle money have decided that it is cheaper to wait for you to notice that money is missing, contact them, and then credit your account (maybe). And if you don't notice, well... it's not their responsibility.

    I think that it is in the interests of businesses as well as their customers for SSL transactions to remain secure.

    I would think so, too. However, people who run these companies' IT appear to have come to a different conclusion: Spend a certain amount of money on a somewhat secure system, and then put the responsibility on the customer to notice fraud. If noticed, credit the customer's account. Since the problems with mixing secure and non-secure elements have been known and exploited for years, we can conclude that these companies have done their cost-benefit analysis on the current way of doing things and found it to be acceptable.

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Working...