• T
    Add TLSv1.3 post-handshake authentication (PHA) · 9d75dce3
    Todd Short 提交于
    Add SSL_verify_client_post_handshake() for servers to initiate PHA
    
    Add SSL_force_post_handshake_auth() for clients that don't have certificates
    initially configured, but use a certificate callback.
    
    Update SSL_CTX_set_verify()/SSL_set_verify() mode:
    
    * Add SSL_VERIFY_POST_HANDSHAKE to postpone client authentication until after
    the initial handshake.
    
    * Update SSL_VERIFY_CLIENT_ONCE now only sends out one CertRequest regardless
    of when the certificate authentication takes place; either initial handshake,
    re-negotiation, or post-handshake authentication.
    
    Add 'RequestPostHandshake' and 'RequirePostHandshake' SSL_CONF options that
    add the SSL_VERIFY_POST_HANDSHAKE to the 'Request' and 'Require' options
    
    Add support to s_client:
    * Enabled automatically when cert is configured
    * Can be forced enabled via -force_pha
    
    Add support to s_server:
    * Use 'c' to invoke PHA in s_server
    * Remove some dead code
    
    Update documentation
    
    Update unit tests:
    * Illegal use of PHA extension
    * TLSv1.3 certificate tests
    
    DTLS and TLS behave ever-so-slightly differently. So, when DTLS1.3 is
    implemented, it's PHA support state machine may need to be different.
    Add a TODO and a #error
    
    Update handshake context to deal with PHA.
    
    The handshake context for TLSv1.3 post-handshake auth is up through the
    ClientFinish message, plus the CertificateRequest message. Subsequent
    Certificate, CertificateVerify, and Finish messages are based on this
    handshake context (not the Certificate message per se, but it's included
    after the hash). KeyUpdate, NewSessionTicket, and prior Certificate
    Request messages are not included in post-handshake authentication.
    
    After the ClientFinished message is processed, save off the digest state
    for future post-handshake authentication. When post-handshake auth occurs,
    copy over the saved handshake context into the "main" handshake digest.
    This effectively discards the any KeyUpdate or NewSessionTicket messages
    and any prior post-handshake authentication.
    
    This, of course, assumes that the ID-22 did not mean to include any
    previous post-handshake authentication into the new handshake transcript.
    This is implied by section 4.4.1 that lists messages only up to the
    first ClientFinished.
    Reviewed-by: NBen Kaduk <kaduk@mit.edu>
    Reviewed-by: NMatt Caswell <matt@openssl.org>
    (Merged from https://github.com/openssl/openssl/pull/4964)
    9d75dce3
extensions_srvr.c 62.9 KB