TLS renegotiation

[hannesm]

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

• https://tools.ietf.org/html/rfc5746

[hannesm]

I actually believe this has been addressed enough:

• we always send TLS_EMPTY_RENEGOTIATION_INFO_SCSV in https://github.com/mirleft/ocaml-tls/blob/master/lib/client.ml#L179
• we require this to be received by the server in https://github.com/mirleft/ocaml-tls/blob/master/lib/server.ml#L112 (on first client hello)
• we require the extension to be present and having the correct value, client: https://github.com/mirleft/ocaml-tls/blob/master/lib/client.ml#L24 (and 29 to check for the correct value) server: https://github.com/mirleft/ocaml-tls/blob/master/lib/server.ml#L100 (and 104 checking the correct value) on subsequent client hellos

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

[hannesm]

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

[pqwy]

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.