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 Subject: RE: Use of TLS_FALLBACK_SCSV 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
