-
Notifications
You must be signed in to change notification settings - Fork 67
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
Session hash #287
Session hash #287
Conversation
interop (of extended master secret) was tested successfully with polarssl |
97eb00f
to
f9bd6e8
Compare
…ange, and depending on session.extended_ms computes the extended or normal master secret
f9bd6e8
to
aa39f2a
Compare
…therwise, do full handshake), always send extended_ms in clienthello, use in serverhello if sent by client
aa39f2a
to
dac9e39
Compare
rebased to master. This change integrates session hash (RFC 7627), and only proceeds with resuming a session if the old and new session support session hash, to prevent triple handshake mitm attacks. might be a bit too conservative for the use case where someone runs a public web server and wants to get speed improvements from resumption; there enabling resumption if renegotiation is off should be secure. |
…t is used In answer_server_hello_renegotiate, the session never set extended_ms to true, which needs to be the case if both ServerHello and ClientHello contained the extension. The asymmetry between answer_server_hello and answer_server_hello_renegotiate was introduced in June 2015 (0.7.0, commit dac9e39, PR mirleft#287). A test setup is to run mbedtls_ssl_server2 renegotiate=1 renegotiation=1 renego_period=2 exchanges=3 and on our other side a test_client or similar where ~reneg:true is passed to Config.client. Instead of copy and pasting code betweent the two functions, I took the opportunity to unify some parts into common functions (as was already partially done with valid_cipher).
…t is used In answer_server_hello_renegotiate, the session never set extended_ms to true, which needs to be the case if both ServerHello and ClientHello contained the extension. The asymmetry between answer_server_hello and answer_server_hello_renegotiate was introduced in June 2015 (0.7.0, commit dac9e39, PR mirleft#287). A test setup is to run mbedtls_ssl_server2 renegotiate=1 renegotiation=1 renego_period=2 exchanges=3 and on our other side a test_client or similar where ~reneg:true is passed to Config.client. Instead of copy and pasting code betweent the two functions, I took the opportunity to unify some parts into common functions (as was already partially done with valid_cipher).
…t is used In answer_server_hello_renegotiate, the session never set extended_ms to true, which needs to be the case if both ServerHello and ClientHello contained the extension. The asymmetry between answer_server_hello and answer_server_hello_renegotiate was introduced in June 2015 (0.7.0, commit dac9e39, PR mirleft#287). A test setup is to run mbedtls_ssl_server2 renegotiate=1 renegotiation=1 renego_period=2 exchanges=3 and on our other side a test_client or similar where ~reneg:true is passed to Config.client. Instead of copy and pasting code betweent the two functions, I took the opportunity to unify some parts into common functions (as was already partially done with valid_cipher).
based on resumption #283 an implementation of session hash (proposed draft). resumption is only possible if an extended_master_secret was used (due to triple handshake the only sensible way to deal with it)