Project

General

Profile

Actions
Copy link

Bug #2098

closed

OpenSSL renegotiation vulnerability

Added by silverfire over 14 years ago. Updated over 14 years ago.

Status:
Invalid
Priority:
Normal
Category:
core
Target version:
-
ASK QUESTIONS IN Forums:

Description

http://www.ietf.org/mail-archive/web/tls/current/msg03928.html
http://tools.ietf.org/html/draft-rescorla-tls-renegotiation-00

Potential man-in-the middle attack that appears to need a fix on both the client and server side.

Actions
Copy link
 #1

Updated by darix over 14 years ago

yeah it needs a fix in your openssl implementation. what apache did was just a workaround for installations of openssl without the fix afaik.

Actions
Copy link
 #2

Updated by guidot over 14 years ago

This is from http://blog.g-sec.lu/2009/11/tls-sslv3-renegotiation-vulnerability.html:

Vulnerability requirements

The preconditions for a TLS or SSLv3 connection to be vulnerable are
  1. The server acknowledges and accepts full TLS renegotiations in the middle of a
    connection and after the initial handshake
    and
  2. The server assumes that both TLS sessions were negotiated with the same client
    and
  3. The server treats both sessions as one and merges them at the application layer

As such this vulnerability might not been seen as a vulnerability in TLS but the as the bad choice
to merge two different requests together by the endpoint.

Actions
Copy link
 #3

Updated by stbuehler over 14 years ago

  • Status changed from New to Invalid

I disagree. If the ssl implementation does a "full renegotation" it still has to verify that the remote endpoint doesn't change, everything else is just stupid. It is not the job of the application to handle this; that is the point of using a library.

Actions
Copy link

Also available in: Atom