Skip to content
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
Closed

TLS renegotiation #3

hannesm opened this issue Mar 3, 2014 · 3 comments

Comments

@hannesm
Copy link
Member

@hannesm 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 mentioned this issue Mar 3, 2014
hannesm added a commit that referenced this issue Mar 3, 2014
bail out if the extension or ciphersuite is not present in the
handshake. addresses #3
@hannesm
Copy link
Member Author

@hannesm 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
Copy link
Member Author

@hannesm 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
Copy link
Contributor

@pqwy 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
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants