aboutsummaryrefslogtreecommitdiffstats
path: root/erts/obj.debug
diff options
context:
space:
mode:
authorIngela Anderton Andin <[email protected]>2017-04-21 10:22:26 +0200
committerIngela Anderton Andin <[email protected]>2017-04-21 14:38:01 +0200
commitedab501fe7bffe3f19871157ebd1851e6dad1bc5 (patch)
treecfaef4f8dfda3d240be8669e3e118d27a8cd90ee /erts/obj.debug
parent3f124994d35cbfc5158b89f91c16d4db6615d3fb (diff)
downloadotp-edab501fe7bffe3f19871157ebd1851e6dad1bc5.tar.gz
otp-edab501fe7bffe3f19871157ebd1851e6dad1bc5.tar.bz2
otp-edab501fe7bffe3f19871157ebd1851e6dad1bc5.zip
ssl: TLS-1.2 clients will now always send hello messages on its own format.
Note this is a change form how it works for earlier versions that will send the first hello message on the lowest supported version. From RFC 5246 Appendix E. Backward Compatibility E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 Since there are various versions of TLS (1.0, 1.1, 1.2, and any future versions) and SSL (2.0 and 3.0), means are needed to negotiate the specific protocol version to use. The TLS protocol provides a built-in mechanism for version negotiation so as not to bother other protocol components with the complexities of version selection. TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages; thus, supporting all of them is relatively easy. Similarly, servers can easily handle clients trying to use future versions of TLS as long as the ClientHello format remains compatible, and the client supports the highest protocol version available in the server. A TLS 1.2 client who wishes to negotiate with such older servers will send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in ClientHello.client_version. If the server does not support this version, it will respond with a ServerHello containing an older version number. If the client agrees to use this version, the negotiation will proceed as appropriate for the negotiated protocol. If the version chosen by the server is not supported by the client (or not acceptable), the client MUST send a "protocol_version" alert message and close the connection. If a TLS server receives a ClientHello containing a version number greater than the highest version supported by the server, it MUST reply according to the highest version supported by the server. A TLS server can also receive a ClientHello containing a version number smaller than the highest supported version. If the server wishes to negotiate with old clients, it will proceed as appropriate for the highest version supported by the server that is not greater than ClientHello.client_version. For example, if the server supports TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will proceed with a TLS 1.0 ServerHello. If server supports (or is willing to use) only versions greater than client_version, it MUST send a "protocol_version" alert message and close the connection. Whenever a client already knows the highest protocol version known to a server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol. Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will refuse the connection if any TLS extensions are included in ClientHello. Interoperability with such buggy servers is a complex topic beyond the scope of this document, and may require multiple connection attempts by the client. Earlier versions of the TLS specification were not fully clear on what the record layer version number (TLSPlaintext.version) should contain when sending ClientHello (i.e., before it is known which version of the protocol will be employed). Thus, TLS servers compliant with this specification MUST accept any value {03,XX} as the record layer version number for ClientHello. TLS clients that wish to negotiate with older servers MAY send any value {03,XX} as the record layer version number. Typical values would be {03,00}, the lowest version number supported by the client, and the value of ClientHello.client_version. No single value will guarantee interoperability with all old servers, but this is a complex topic beyond the scope of this document.
Diffstat (limited to 'erts/obj.debug')
0 files changed, 0 insertions, 0 deletions