Home
last modified time | relevance | path

Searched refs:handshake (Results 1 – 25 of 118) sorted by relevance

12345

/freebsd/crypto/openssl/test/ssl-tests/
H A D26-tls13_client_auth.cnf11 test-6 = 6-client-auth-TLSv1.3-request-post-handshake
12 test-7 = 7-client-auth-TLSv1.3-require-fail-post-handshake
13 test-8 = 8-client-auth-TLSv1.3-require-post-handshake
14 test-9 = 9-client-auth-TLSv1.3-require-non-empty-names-post-handshake
15 test-10 = 10-client-auth-TLSv1.3-noroot-post-handshake
16 test-11 = 11-client-auth-TLSv1.3-request-force-client-post-handshake
17 test-12 = 12-client-auth-TLSv1.3-request-force-server-post-handshake
18 test-13 = 13-client-auth-TLSv1.3-request-force-both-post-handshake
210 [6-client-auth-TLSv1.3-request-post-handshake]
211 ssl_conf = 6-client-auth-TLSv1.3-request-post-handshake-ssl
[all …]
H A D26-tls13_client_auth.cnf.in12 ## TLSv1.3 and post-handshake authentication
133 name => "client-auth-TLSv1.3-request-post-handshake",
149 name => "client-auth-TLSv1.3-require-fail-post-handshake",
166 name => "client-auth-TLSv1.3-require-post-handshake",
193 name => "client-auth-TLSv1.3-require-non-empty-names-post-handshake",
221 name => "client-auth-TLSv1.3-noroot-post-handshake",
243 name => "client-auth-TLSv1.3-request-force-client-post-handshake",
262 name => "client-auth-TLSv1.3-request-force-server-post-handshake",
281 name => "client-auth-TLSv1.3-request-force-both-post-handshake",
/freebsd/crypto/openssl/doc/man3/
H A DSSL_CTX_set_tlsext_servername_callback.pod47 handshake will be aborted. The value of the alert to be used should be stored in
54 However, the handshake will continue and send a warning alert instead. The value
72 handshake. In TLSv1.2 the servername is only negotiated on initial handshakes
77 =item On the client, before the handshake
83 session from the original handshake had a servername accepted by the server then
88 =item On the client, during or after the handshake and a TLSv1.2 (or below)
91 If the session from the original handshake had a servername accepted by the
97 =item On the client, during or after the handshake and a TLSv1.2 (or below)
103 =item On the server, before the handshake
105 The function will always return NULL before the handshake
[all …]
H A DSSL_do_handshake.pod5 SSL_do_handshake - perform a TLS/SSL handshake
15 SSL_do_handshake() will wait for a SSL/TLS handshake to take place. If the
16 connection is in client mode, the handshake will be started. The handshake
26 once the handshake has been finished or an error occurred.
30 to continue the handshake. In this case a call to SSL_get_error() with the
47 The TLS/SSL handshake was not successful but was shut down controlled and
53 The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
58 The TLS/SSL handshake was not successful because a fatal error occurred either
H A DSSL_connect.pod5 SSL_connect - initiate the TLS/SSL handshake with an TLS/SSL server
15 SSL_connect() initiates the TLS/SSL handshake with a server. The communication
24 handshake has been finished or an error occurred.
28 to continue the handshake, indicating the problem by the return value -1.
41 impacts after a successful TLSv1.3 handshake or a successful TLSv1.2 (or below)
42 resumption handshake, because the last peer to communicate in the handshake is
45 been received for the final handshake message.
61 The TLS/SSL handshake was not successful but was shut down controlled and
67 The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
72 The TLS/SSL handshake was not successful, because a fatal error occurred either
H A DSSL_accept.pod5 SSL_accept - wait for a TLS/SSL client to initiate a TLS/SSL handshake
15 SSL_accept() waits for a TLS/SSL client to initiate the TLS/SSL handshake.
24 handshake has been finished or an error occurred.
28 to continue the handshake, indicating the problem by the return value -1.
46 The TLS/SSL handshake was not successful but was shut down controlled and
52 The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
57 The TLS/SSL handshake was not successful because a fatal error occurred either
H A DSSL_in_init.pod11 - retrieve information about the handshake state machine
29 awaiting handshake messages, or 0 otherwise.
31 SSL_in_before() returns 1 if no SSL/TLS handshake has yet been initiated, or 0
48 SSL_get_state() returns a value indicating the current state of the handshake
62 B<message> is the name of a handshake message that is being or has been sent, or
72 No handshake messages have yet been been sent or received.
93 SSL_get_state() returns the current handshake state.
H A DSSL_key_update.pod34 SSL_key_update() must only be called after the initial handshake has been
51 handshake over an existing SSL/TLS connection. The next time an IO operation
56 handshake.
60 session associated with the current connection in the new handshake.
64 for a new handshake to be sent to the client. The next time an IO operation is
67 handshake and it may or may not attempt to resume an existing session. If
68 a new handshake is started then this will be handled transparently by calling
74 new handshake. For historical reasons, DTLS clients will not attempt to resume
75 the session in the new handshake.
H A DSSL_CTX_set_ct_validation_callback.pod41 TLS handshake with the verification mode set to B<SSL_VERIFY_PEER>, if the peer
42 presents no valid SCTs the handshake will be aborted.
43 If the verification mode is B<SSL_VERIFY_NONE>, the handshake will continue
49 handshake completion, even after session resumption since the verification
54 handshake continues, and the verification status is not modified, regardless of
57 handshake completion.
59 the handshake.
61 handshake completion, such delayed SCT checks should only be performed when the
69 The TLS handshake is aborted if the verification mode is not B<SSL_VERIFY_NONE>
82 In that case the handshake continues as it would had no callback been
H A DSSL_CTX_set_num_tickets.pod26 the client after a full handshake. Set the desired value (which could be 0) in
28 the start of the handshake.
35 Tickets are also issued on receipt of a post-handshake certificate from the
40 was used for the initial handshake. If the initial handshake was a full
41 handshake then SSL_set_num_tickets() can be called again prior to calling
48 sent in this manner after the initial handshake has completed, and only for
H A DSSL_CTX_set_verify.pod52 This makes the handshake suspend and return control to the calling application
59 Note that the handshake may still be aborted if a subsequent invocation of the
70 post-handshake authentication can be requested by the server. If B<val> is 0
93 certificate verification process can be checked after the TLS/SSL handshake
95 The handshake will be continued regardless of the verification result.
101 fails, the TLS/SSL handshake is
109 fails, the TLS/SSL handshake is
117 handshake is immediately terminated with a "handshake failure" alert.
127 during the initial handshake
[all...]
H A DSSL_CTX_set_cert_cb.pod26 been set. A zero is returned on error which will abort the handshake with a
27 fatal internal error alert. A negative return value will suspend the handshake
28 and the handshake function will return immediately.
30 indicate, that the handshake was suspended. The next call to the handshake
50 A more advanced callback might examine the handshake parameters and set
H A DSSL_set_connect_state.pod35 When beginning a new handshake, the SSL engine must know whether it must
38 requested, the handshake routines must be explicitly set.
41 L<SSL_accept(3)> routines, the correct handshake
44 the handshake routines must be explicitly set in advance using either
H A DSSL_CTX_set_info_callback.pod69 Callback has been called to indicate exit of a handshake function. This will
70 happen after the end of a handshake, but may happen at other times too such as
99 Callback has been called because a new handshake is started. It also occurs when
100 resuming a handshake following a pause to handle early data.
104 Callback has been called because a handshake is finished. It also occurs if the
105 handshake is paused to allow the exchange of early data.
H A DSSL_CTX_set_client_hello_cb.pod32 also return a negative value to suspend the handshake, and the handshake
34 SSL_ERROR_WANT_CLIENT_HELLO_CB to indicate that the handshake was suspended.
36 of the last call if needed to continue. On the next call into the handshake
38 success, normal handshake processing will continue from that point.
74 code to affect the TLS handshake. A primary use of the callback is to
H A DSSL_CTX_set_psk_client_callback.pod57 be freed by it as required at any point after the handshake is complete.
71 Only the handshake digest associated with the ciphersuite is relevant for the
74 not NULL the handshake digest for the ciphersuite should be the same.
76 handshake digest of an SSL_CIPHER object can be checked using
90 Alternatively an SSL_SESSION created from a previous non-PSK handshake may also
97 case no PSK will be sent to the server but the handshake will continue. To do
125 always be NULL and the handshake digest will default to SHA-256 for any returned
H A DSSL_CTX_set_client_cert_cb.pod33 will be sent. A negative return value will suspend the handshake and the
34 handshake function will return immediately. L<SSL_get_error(3)>
35 will return SSL_ERROR_WANT_X509_LOOKUP to indicate, that the handshake was
36 suspended. The next call to the handshake function will again lead to the call
42 During a handshake (or renegotiation) a server may request a certificate
H A DSSL_get_certificate.pod34 selected during the handshake, or NULL if no certificate was selected (for
39 Certificate selection occurs during the handshake; therefore, the value returned
40 by SSL_get_certificate() during any callback made during the handshake process
H A DSSL_CTX_set_cert_verify_callback.pod23 When a peer certificate has been received during a SSL/TLS handshake,
35 In server mode, a return value of 0 leads to handshake failure.
39 Otherwise, when the return value is less than or equal to 0, the handshake will
46 to succeed. This makes the handshake suspend and return control to the
H A DDTLSv1_listen.pod23 enable the handshake to be completed (for example by using SSL_accept()).
30 address. An attacker could forge its source IP address and then send handshake
59 where the handshake can be continued by a call to (for example) SSL_accept().
65 the peer and continue the handshake in a connected state.
77 denial-of-service attack or allow unencrypted information in the DTLS handshake
109 will be set up ready to continue the handshake. A return value of 0 or -1
114 will be set up ready to continue the handshake. the B<peer> value will also be
H A DSSL_clear.pod30 used during the session will be kept for the next handshake. So if the
32 method for the next handshake and a SSL server object will use a TLSv1
42 handshake). It only makes sense for a new connection with the exact
H A DSSL_session_reused.pod5 SSL_session_reused - query whether a reused session was negotiated during handshake
15 Query, whether a reused session was negotiated during the handshake.
/freebsd/crypto/openssl/test/
H A DREADME.ssltest.md38 * HandshakeMode - which handshake flavour to test:
39 - Simple - plain handshake (default)
44 When HandshakeMode is Resume or Renegotiate, the original handshake is expected
46 handshake.
55 both client and server. Lowering the fragment size will split handshake and
63 * ExpectedResult - expected handshake outcome. One of
64 - Success - handshake success
65 - ServerFail - serverside handshake failure
66 - ClientFail - clientside handshake failure
90 - Yes - resumed handshake
[all …]
/freebsd/crypto/openssl/ssl/statem/
H A DREADME.md19 - Separate message flow state from handshake state (in order to better
24 * handshake state = what handshake message are we working on now
/freebsd/contrib/bearssl/src/ssl/
H A Dssl_hs_common.t024 \ This is the common T0 code for processing handshake messages (code that
47 \ of the handshake; and it is cleared whenever a renegotiation or a
61 \ The handshake processor needs to defer back to the caller ('co') only
64 \ -- Some handshake data is expected.
66 \ -- The handshake is finished, and application data may flow. There may
67 \ be some incoming handshake data (HelloRequest from the server). This
283 \ 0x01 handshake data is available
285 \ 0x04 some data other than handshake or change-cipher-spec is available
429 \ If the current record type is "handshake" then the read byte is also
452 \ If the current record type is "handshake" then the read bytes are
[all …]

12345