search

project-everest / mitls-fstar

Verified implementation of TLS 1.3 in F*
https://www.mitls.org
Other
173 stars 16 forks source link

miTLS and NSS servers emit different alerts when manipulating EncryptedExtensions #175

Open oweisse-msft opened 7 years ago

oweisse-msft commented 7 years ago

Items inside EncryptedExtensions are shuffled, and encrypted with the correct server handshake key. The miTLS client responds with plaintext-alert  bad_certificate, while NSS client doesn’t emit an alert (potential NSS issue) .   

  1. In case of miTLS server and miTLS client (emitting bad_certificate), the miTLS client response will be encrypted-alert of type   decryption_failed_RESERVED
  2. In case of NSS server and miTLS client (emitting bad_certificate), the miTLS client response will be encrypted-alert of type   bad_record_mac (that sounds right, since the MAC doesn't fit the re-ordered message from the server).
  3. In case of miTLS server and NSS client (which is not emitting an alert), FFI_mitls_accept_connect is completed successfully, even though the client's Finished has not been sent.
beurdouche commented 7 years ago

@oweisse-msft Does NSS close the connection instead of sending an alert or does it keep going ? 1 - Sending a 'RESERVED' value with TLS 1.3 doesn't seem good. 3 - Not good.

BarryBo commented 6 years ago

Can you follow up on this bug? Please check if it is still and issue, and if it'll be caught/fixed as part of the verification push?