New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TLS renegotiation #3

Closed
hannesm opened this Issue Mar 3, 2014 · 3 comments

Comments

2 participants
@hannesm
Member

hannesm commented Mar 3, 2014

problem: a man in the middle might hand over a TLS session to a client, because key renegotiation does not include any data from the previous key exchange

solution: secure renegotiation, as specified in RFC 5746

@hannesm hannesm referenced this issue Mar 3, 2014

Closed

Confidence? #1

hannesm added a commit that referenced this issue Mar 3, 2014

Require secure renegotiation (RFC 5746)
bail out if the extension or ciphersuite is not present in the
handshake. addresses #3
@hannesm

This comment has been minimized.

Member

hannesm commented Mar 5, 2014

I actually believe this has been addressed enough:

I can think of the extension being send multiple times, but that shouldn't hurt anything (each of it must be correct).

@hannesm

This comment has been minimized.

Member

hannesm commented Apr 11, 2014

I am convinced this issue is also solved in our stack, but would love to have another pair of eyes reviewing.

pqwy added a commit that referenced this issue May 4, 2014

@pqwy

This comment has been minimized.

Contributor

pqwy commented Jul 7, 2014

Stuff floated around in the meantime, but we do always send and check TLS_EMPTY_RENEGOTIATION_INFO_SCSV and have a config option to control whether to bail out if the peer doesn't support it.

Looks legit.

@pqwy pqwy closed this Jul 7, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment