Re: Swiss Researchers Find A Hole In SSL

2003-02-23 Thread Eric Rescorla
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

2003-02-23 Thread Eric Rescorla
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

2003-02-23 Thread Anton Stiglic
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

2003-02-23 Thread John F. McMullen
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

2003-02-23 Thread Zully Ramzan
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]