Re: Swiss Researchers Find A Hole In SSL
Vin McLellan [EMAIL PROTECTED] writes: 4. Is this an issue for the client or the server? Normally, this would only be an issue for the server (i.e., the party that receives the connection request), since normal SSL clients don't automatically large numbers of connections. It's worth noting that the paper describes a specific client (Outlook) that in fact does gneerate large numbers of connections. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Bodo Moeller bodo@openssl.org] OpenSSL Security Advisory: Timing-based attacks on SSL/TLS with CBC encryption
Steven M. Bellovin [EMAIL PROTECTED] writes: I'm struck by the similarity of this attack to Matt Blaze's master key paper. In each case, you're guessing at one position at a time, and using the response of the security system as an oracle. What's crucial in both cases is the one-at-a-time aspect -- that's what makes the attack linear instead of exponential. Indeed. And of course, both attacks resemble the old password guessing attack on character by character passwords where you time how long password verification takes. (The details are pretty hazy but ISTR that you arranged for the password to cross a page boundary to increase the time discrimination). -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Bodo Moeller bodo@openssl.org] OpenSSL Security Advisory: Timing-based attacks on SSL/TLS with CBC encryption
If I'm not mistaken, the OpenSSL spec says that you should MAC the (compressed) message, and then encrypt the message and the MAC. This composition is not generically secure, on the other hand you can prove some nice things about the composition encrypt-then- MAC assuming certain conditions, see for example David Wagner's post on sci.crypt for a discussion about that: http://groups.google.ca/groups?q=sci.crypt+encrypt+then+authenticate+Wagner; hl=enlr=ie=UTF-8oe=UTF-8selm=aj77jo%241ko%241%40agate.berkeley.edurnum= 1 (using CBC-DES with a random IV and then HMAC, with a KDF that derives independent keys for the encryption and the MACing (the KDF in SSL looks like it can do this) would satisfy these conditions.) I now always recommend encrypt-then-MAC. If SSL required encrypt-then-MAC, a programmer would more naturally start by verifying the MAC, then decrypt the message, so Vaudenay's attack would be caught first by the MAC verification and the implementation would probably return an error after the MAC verification and not leak the information needed to discover the plaintext. So even though the attack is not directly the result of the SSL protocol spec, a spec which would favor encrypt-then-MAC would be better in my point of view and the security holes relating to this SSLattack in implementations might have much less of a chance of existing. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Hackers Run Wild and Free on AOL
From Wired News -- http://www.wired.com/news/infostructure/0,1377,57753,00.html?tw=wn_ascii Hackers Run Wild and Free on AOL By Christopher Null Using a combination of trade tricks and clever programming, hackers have thoroughly compromised security at America Online, potentially exposing the personal information of AOL's 35 million users. The most recent exploit, launched last week, gave a hacker full access to Merlin, AOL's latest customer database application. As a security measure, Merlin runs only on AOL's internal network, but savvy hackers have found a way to break in. The hack involves tricking an AOL employee into accepting a file using Instant Messenger or uploading a Trojan horse to an AOL file library. When the file is executed, the Trojan horse connects the user who launched it to an Internet relay chat server, which the hacker can use to issue commands on the targeted machine. This allows the hacker to enter the internal AOL network and the Merlin application. Merlin requires a user ID, two passwords and a SecurID code, all of which hackers obtain by spamming the AOL employee database with phony security updates, through online password trades, or by social engineering attacks over IM or the telephone. The hacker who first used this exploit is said to be a 14-year-old boy. (He could not be reached for comment.) Another recent exploit reportedly allowed anyone to log in to any account with a password, using a hole in AOL's Japanese Webmail portal. That flaw has since been repaired. Yet another hole has allowed hackers to steal AOL Instant Messenger screen names, even those of AOL staff members and executives. Most at risk are screen names that hackers covet, like Graffiti, or single-word names like Steve. Also at risk are internal AOL accounts like TOSGeneral, which is used to monitor abuse reports. While many of these hacks utilize programming bugs, most hackers are finding it far easier and quicker to get access or information simply by calling the company on the phone. These so-called social engineering tactics involve calling AOL customer support centers and simply asking to have a given user's password reset. Logging in with the new password gives the intruder full access to the account. In a telephone interview, two hackers using the handles Dan and Cam0 explained that security measures (such as verifying the last four digits of a credit card number) can be bypassed by mumbling. A third hacker, using the name hakrobatik, confirmed the mumbling method. I kept calling and pretending I just had jaw surgery and mumbling gibberish, hakrobatik said. At first I had no info except the screen name, then I called and got the first name and last name by saying, 'Could you repeat what I just said?' Then each time that I got information I called back making the real information understandable, and everything else I just mumbled. In the end, hakrobatik said, service reps he talked to got so frustrated having to ask him to repeat information that they'd give up and reset the password. Hakrobatik later proved he could compromise any AOL account armed only with its screen name. Typically, hackers target reps at offshore call centers in India or Mexico, who they claim are less savvy and have far less training than American service agents. You can basically get any account information from AOL by just calling and pestering, hakrobatik said. At least one rep was susceptible to the proverbial oldest trick in the book. Cam0 said he masqueraded as a teenage girl to win favors from a smitten AOL employee after engaging in flirtatious chat sessions and sending phony photographs. Some hackers also pose as internal AOL Operations Security staff to wheedle information. And hackers claim disgruntled AOL employees freely provide account information and favors to friends on the outside. Of the latest AOL attacks, Adrian Lamo, renowned hacker and founder of disbanded watchdog site Inside-AOL, said: It's unprecedented in the history of AOL. AOL employee education is centered around fake online communication. There's very little effort to guard against voice scams. Why hasn't AOL let users know about the site's rampant security problems? Every now and then something flashy happens, but AOL keeps it quiet pretty effectively, Lamo said. The reason, Lamo said, is that AOL rarely prosecutes hackers. They tend to employ technical countermeasures and otherwise ignore intruders, he said. There's an oft-stated perception that no one has ever been busted for hacking an AOL account. AOL did not return repeated calls requesting comment for this story. You see all those commercials saying AOL 8.0 is so secure, said Dan. If people knew how insecure their data was they probably wouldn't use it. Copyright 2003, Lycos, Inc. *** FAIR USE NOTICE. This message contains copyrighted material whose use has not been specifically authorized by the copyright owner. The 'johnmacsgroup' Internet discussion group is
RE: [Bodo Moeller bodo@openssl.org] OpenSSL Security Advisory: Timing-based attacks on SSL/TLS with CBC encryption
The idea is also similar to timing attacks against very, very badly-implemented password checking schemes; e.g. where a reply by some verifying server to a correct guess on the first n characters of a password takes slightly longer than a reply to a correct guess on only the initial n-1 characters (because an error is returned as soon as the first character is encountered). In these cases, the attack is also linear since one character at a time can be guessed, and the timing of the response provides an indication of whether or not the guess is correct. I believe we've also seen this type of paradigm in many cryptanalytic instances wherein a guess for just a portion of a secret key can be verified, thereby reducing the time for a brute-force search since one first guesses this portion, and gets it right, before trying to guess the remainder of the key material. Regards, Zully ~ Zulfikar Ramzan IP Dynamics, Inc. http://www.ipdynamics.com Unfettered, Simple VPNs -Original Message- From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] Sent: Friday, February 21, 2003 6:17 AM To: EKR Cc: [EMAIL PROTECTED] Subject: Re: [Bodo Moeller [EMAIL PROTECTED]] OpenSSL Security Advisory: Timing- based attacks on SSL/TLS with CBC encryption I'm struck by the similarity of this attack to Matt Blaze's master key paper. In each case, you're guessing at one position at a time, and using the response of the security system as an oracle. What's crucial in both cases is the one-at-a-time aspect -- that's what makes the attack linear instead of exponential. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]