But my understanding is that it requires the same content to be submitted 
repeatedly within a single session with manipulations to the padding to 
incrementally decrypt the content; we use ssl to protect our session 
establishment - think of a SIP call, SIP INVITE (offer) in one direction and 
SIP ACK (accept/refuse) in the other to establish session parameters and then 
the ssl connection is torn down and a different (non-ssl) encryption mechanism 
is used to protect the actual media stream. Any attempt to retransmit either 
INVITE or ACK will abort the session and in any case, no further sensitive 
material is sent subsequently to the ACK in the ssl session (there’s the 
equivalent of a BYE/BYE ACK).

We plan to disable sslv3 anyway because we want to avoid being at risk in the 
future (and you point out a good argument for disabling the fallback in 
general) but within our controlled scenario, I don’t think we’re vulnerable to 
a POODLE attack unless there’s something I’m missing … N

From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Salz, Rich
Sent: October-16-14 4:24 PM
To: openssl-users@openssl.org

It does not matter who you talk to.  With a POODLE attack, your content can be 
decrypted.  Cookies, etc., were just used as an example.

Disabling ssl3 is a good thing.  But set the fallback because silently dropping 
from tls 1.2 to tls 1.1 is bad.  It’s done during the handshake process as part 
of the cipher negotiation.

Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me<mailto:rs...@jabber.me> Twitter: RichSalz

Reply via email to