Home
last modified time | relevance | path

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

1234567

/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
145 name => "client-auth-TLSv1.3-request-post-handshake",
161 name => "client-auth-TLSv1.3-require-fail-post-handshake",
178 name => "client-auth-TLSv1.3-require-post-handshake",
205 name => "client-auth-TLSv1.3-require-non-empty-names-post-handshake",
233 name => "client-auth-TLSv1.3-noroot-post-handshake",
255 name => "client-auth-TLSv1.3-request-force-client-post-handshake",
274 name => "client-auth-TLSv1.3-request-force-server-post-handshake",
293 name => "client-auth-TLSv1.3-request-force-both-post-handshake",
H A D04-client_auth.cnf.in69 # Sanity-check simple handshake.
140 # Successful handshake with client authentication.
170 # Successful handshake with client RSA-PSS cert, StrictCertCheck
198 # Failed handshake with client RSA-PSS cert, StrictCertCheck, bad CA
229 # Successful handshake with client authentication non-empty names
/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 an 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_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
50 SSL_get_state() returns a value indicating the current state of the handshake
64 B<message> is the name of a handshake message that is being or has been sent, or
74 No handshake messages have yet been been sent or received.
95 SSL_get_state() returns the current handshake state.
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_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_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. This flag must be used together with
135 during the initial handshake, but will send the request via
[all …]
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_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_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. Note that some servers will respond to reneogitation attempts with
62 session associated with the current connection in the new handshake.
66 for a new handshake to be sent to the client. The next time an IO operation is
69 handshake and it may or may not attempt to resume an existing session. If
70 a new handshake is started then this will be handled transparently by calling
76 new handshake. For historical reasons, DTLS clients will not attempt to resume
77 the session in the new handshake.
H A DSSL_get_handshake_rtt.pod22 This metric is created by taking two timestamps during the handshake and
44 Returns 1 if the TLS handshake RTT is successfully retrieved.
45 Returns 0 if the TLS handshake RTT cannot be determined yet.
46 Returns -1 if, while retrieving the TLS handshake RTT, an error occurs.
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_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 handshake. Since ownership of the SSL_SESSION is transferred to OpenSSL on each
105 case no PSK will be sent to the server but the handshake will continue. To do
133 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
/freebsd/crypto/openssl/doc/designs/quic-design/
H A Dquic-thread-assist.md8 Part of the QUIC state comprises the TLS handshake layer. However, synchronising
11 At first glance, one could synchronise handshake layer public APIs by locking a
13 the handshake layer. Since we forward a very large number of APIs to the
14 handshake layer, this would require a very large number of code changes to add
52 In this model, the handshake layer “belongs” to the application thread
60 future which would be processed by the handshake layer.
63 as the handshake layer, the only thing we actually need to worry about
64 servicing after handshake completion is the New Session Ticket message,
66 post-handshake messages used by TLS 1.3 aren't relevant to QUIC TLS:
68 - Post-handshake authentication is not allowed;
[all …]
H A Dquic-tls.md4 QUIC reuses the TLS handshake for the establishment of keys. It does not use
6 confidentiality and integrity of QUIC packets itself. Only the TLS handshake is
12 A QUIC-TLS handshake is managed by a QUIC_TLS object. This object provides
22 various key points during the handshake lifecycle such as when new keys are
24 handshake is complete.
28 handshake state. This is a different `SSL` object to the "user" visible `SSL`
37 When the QUIC Connection no longer needs the handshake object it can be freed
45 state of the QUIC-TLS handshake. On each call to `ossl_quic_tls_tick` newly
87 * Note: These parameters are not authenticated until the handshake is
96 * Called when the handshake has been completed as far as the handshake
[all …]
H A Dquic-fault-injector.md34 handshake data (i.e. the contents of CRYPTO frames). However such faults may
35 need to be done in handshake messages that would normally be encrypted.
36 Additionally the contents of handshake messages are hashed and each peer
39 handshake would fail.
48 that enables modification of handshake data prior to it being encrypted and
71 called after each handshake message has been constructed and is ready to send, but
72 before it has been passed through the handshake hashing code. It will be passed
73 a pointer to the constructed handshake message in `msgin` along with its
74 associated length in `inlen`. The mutator will construct a replacement handshake
167 - An EncryptedExtensions handshake message being sent
[all …]
H A Dconnection-state-machine.md21 QUIC terms such as 'handshake' to avoid confusion, as they are not the same
36 the handshake has been completed but not yet confirmed).
45 packets. It is terminated when the handshake is confirmed.
47 Handshake confirmation is not the same as handshake completion.
51 On the server, handshake confirmation occurs as soon as
52 the handshake is considered completed (see RFC 9001 s. 4.1).
109 an arbitrarily long period until the handshake layer indicates the
113 causes the handshake layer (whether it is TLS 1.3 or some other
114 hypothetical handshake layer) to emit keys for the Handshake EL.
117 handshake layer protocol messages to the handshake layer in use.
[all …]
/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

1234567