back to article Tech titans meet in secret to plug SSL hole

Researchers say they've uncovered a flaw in the secure sockets layer protocol that allows attackers to inject text into encrypted traffic passing between two endpoints. The vulnerability in the transport layer security protocol allows man-in-the-middle attackers to surreptitiously introduce text at the beginning of an SSL …

COMMENTS

This topic is closed for new posts.
  1. Martin 75
    Grenade

    Oh

    I felt a great disturbance, as if a million geeks cried out at once, and were suddenly silenced.

    ps. ah shit :/

  2. Your alien overlord - fear me

    Google it !!

    "in Mountain View, California, at a company they declined to name."

  3. Andraž 'ruskie' Levstik

    So it's another MiM...

    > in large part because they appeared to target a rarely used technology known as client certificate

    > authentication.

    >

    > "It's clever, but to my knowledge the common cases in which the majority of people use SSL

    > (webmail, online banking, etc.) are currently unaffected," he wrote in an email. "I haven't found

    > these attacks to be very useful in practice."

    Hmm so both my online banking which uses client side certs and my cellco control panel which relies on client side certs would be vulnerable then... great... Sure glad that what the majority of people uses is safe. Not that it does them any good.

    I'm less worried about MiM attacks then I am about a bank screwing up their system or me loosing the client cert.

  4. This post has been deleted by its author

  5. Daniel 1

    @Google it !!

    Let's see. Who's got major offices in Mountain view, California... Let me think...

    Symantec

    Verisign

    AOL

    Microsoft's MSN and Mac Business units

    Nokia

    Award Systems

    Mozilla Corporation

    Red Hat

    ... Oh. You ,mean THEM.

    Surely if it had been THEM, then the story would have read "...at a chocolate factory that they declined to name."?

  6. Neal 5

    Tech titans meet in secret to plug SSL hole

    Read all about it !!!!!!!

    Not so secret then, if an ElReg hack knows about it, and it's so hush hush that we've even got the details of the problem, and if I'm not mistaken, an inkling of the solution.

  7. pitagora

    rofl

    @Frank Gerlach: most banks that don't use a digipass either have a totaly unsecure and simple login, OR use CLIENT CERTIFICATES. Yes! Banks use client certificates. It may 0.1% of the users, but that 0.1% are the actual target because they are doing online backing. the rest of the 99.9% are not important to a thief.

  8. Nathan Meyer

    You Can't Fire-Proof A Paper House

    As long as people insist on building paper neworks (IP) and soaking them with flammable applications (active web pages) they will catch fire and burn down.

  9. Anonymous Coward
    Anonymous Coward

    My house is glass

    @Nathan Meyer: What would you recommend in place of IP?

  10. Nathan Meyer

    Fire Resistant House

    Hello theodore.

    The old CCITT protocols X.25 and friends would be a good place to start.

    If you're doing serious business, the call setup and session mangement made life easier and more secure. Consistent routing, packet checks at every hop, anyone tries to break into

    the conversation and the session drops.

    TCP/IP is a nightmare for transaction processing in comparison.

    Lousy for surfing porn sites though; IP much better for that. So IP won.

  11. Anonymous Coward
    Anonymous Coward

    HDLC

    Thanks Nathan. Isn't HDLC (I'm too lazy to google it at 1:30 in the am) a modified version of X.25, I don't remember too much, but the connection between the FEPS back in my mainframe days were HDLC.

    If a black-hat can get into the path of trusted/secure communications, and can capture the entire conversation, including all protocol and encryption negotiations, would they be able to use a botnet to brute-force decrypt the entire stream? This isn't simply a down-side to using the internet, since there is nothing technically different between an internet connection and a leased line, especially since all of the major ISPs are also telecoms. How many encryption passes does one need to apply to a specific dataset to render it irretrievable by entities that are not supposed to be decrypting it? How many times do you have to recursively encrypt a file before you get original input back as the output? I am sure there are ?well? encrypted files that transit the internet, or more likely, leased connections that would be well worth the cost of spinning up an EC2 farm and spending $3 million to decrypt...

This topic is closed for new posts.

Other stories you might like