OpenSSLWiki - User contributions [en]

Simple TLS Client

2022-04-24T20:15:23Z

Philippe lhardy:

You may find an up to date example within repository demos/sslecho together with server ( [[Simple TLS Server]] )

See [[SSL/TLS Client]]

[[Category:Examples]]
[[Category:C level]]

Simple TLS Client

2022-04-24T20:14:08Z

Philippe lhardy:

You may find an up to date example within repository demos/sslecho together with server.

See [[SSL/TLS Client]]

[[Category:Examples]]
[[Category:C level]]

SSL/TLS Client

2022-04-24T20:13:06Z

Philippe lhardy: demos/sslecho and Simple TLS Client

[[SSL/TLS Client]] is sample code for a basic web client that fetches a page. The code shown below omits error checking for brevity, but the sample available for download performs the error checking.

The sample code will set up <tt>BIO</tt> to fet a page from <tt>www.random.org</tt>. The code uses TLS (not SSL) and utilizes the Server Name Indication (SNI) extension from [http://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

If you need features beyond the example below, then you should examine <tt>s_client.c</tt> in the <tt>apps/</tt> directory of the OpenSSL distribution. OpenSSL's <tt>s_client</tt> implements nearly every client side feature available from the library.

The code below does '''not''' perform hostname verification. OpenSSL prior to 1.1.0 does not perform the check, and you must perform the check yourself. The OpenSSL [http://www.openssl.org/news/changelog.html Change Log] for OpenSSL 1.1.0 states you can use <tt>-verify_name</tt> option, and <tt>apps.c</tt> offers <tt>-verify_hostname</tt>. But <tt>s_client</tt> does not respond to either switch, so its unclear how hostname checking will be implemented or invoked for a client. '''Note (N.B.)''': hostname verification is marked as experimental, so switches, options, and implementations could change.

Finally, if you are looking for guidance on which protocols and ciphers you should be using, then see Adam Langley's blog [http://www.imperialviolet.org/2014/12/08/poodleagain.html The POODLE bites again]. The short version: use only TLS 1.2, use only ephemeral key exchanges, and use only AEAD ciphers (like AES/GCM, Camellia/GCM, ChaCha/Poly1305).

== Implementation ==

You may find an up to date example within repository demos/sslecho and [[Simple TLS Client]]

The code below demonstrates a basic client that uses BIOs and TLS to connect to <tt>www.random.org</tt>, and fetches 32 bytes of random data through an HTTP request. The sample code is available for download below.

<pre>#define HOST_NAME "www.random.org"
#define HOST_PORT "443"
#define HOST_RESOURCE "/cgi-bin/randbyte?nbytes=32&format=h"

long res = 1;

SSL_CTX* ctx = NULL;
BIO *web = NULL, *out = NULL;
SSL *ssl = NULL;

init_openssl_library();

const SSL_METHOD* method = SSLv23_method();
if(!(NULL != method)) handleFailure();

ctx = SSL_CTX_new(method);
if(!(ctx != NULL)) handleFailure();

/* Cannot fail ??? */
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);

/* Cannot fail ??? */
SSL_CTX_set_verify_depth(ctx, 4);

/* Cannot fail ??? */
const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION;
SSL_CTX_set_options(ctx, flags);

res = SSL_CTX_load_verify_locations(ctx, "random-org-chain.pem", NULL);
if(!(1 == res)) handleFailure();

web = BIO_new_ssl_connect(ctx);
if(!(web != NULL)) handleFailure();

res = BIO_set_conn_hostname(web, HOST_NAME ":" HOST_PORT);
if(!(1 == res)) handleFailure();

BIO_get_ssl(web, &ssl);
if(!(ssl != NULL)) handleFailure();

const char* const PREFERRED_CIPHERS = "HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4";
res = SSL_set_cipher_list(ssl, PREFERRED_CIPHERS);
if(!(1 == res)) handleFailure();

res = SSL_set_tlsext_host_name(ssl, HOST_NAME);
if(!(1 == res)) handleFailure();

out = BIO_new_fp(stdout, BIO_NOCLOSE);
if(!(NULL != out)) handleFailure();

res = BIO_do_connect(web);
if(!(1 == res)) handleFailure();

res = BIO_do_handshake(web);
if(!(1 == res)) handleFailure();

/* Step 1: verify a server certificate was presented during the negotiation */
X509* cert = SSL_get_peer_certificate(ssl);
if(cert) { X509_free(cert); } /* Free immediately */
if(NULL == cert) handleFailure();

/* Step 2: verify the result of chain verification */
/* Verification performed according to RFC 4158 */
res = SSL_get_verify_result(ssl);
if(!(X509_V_OK == res)) handleFailure();

/* Step 3: hostname verification */
/* An exercise left to the reader */

BIO_puts(web, "GET " HOST_RESOURCE " HTTP/1.1\r\n"
"Host: " HOST_NAME "\r\n"
"Connection: close\r\n\r\n");
BIO_puts(out, "\n");

int len = 0;
do
{
char buff[1536] = {};
len = BIO_read(web, buff, sizeof(buff));

if(len > 0)
BIO_write(out, buff, len);

} while (len > 0 || BIO_should_retry(web));

if(out)
BIO_free(out);

if(web != NULL)
BIO_free_all(web);

if(NULL != ctx)
SSL_CTX_free(ctx);</pre>

== Initialization ==

The sample program initializes the OpenSSL library with <tt>init_openssl_library</tt>. <tt>init_openssl_library</tt> calls three OpenSSL functions.

<pre>#if (SSLEAY_VERSION_NUMBER >= 0x0907000L)
# include <openssl/conf.h>
#endif
...

void init_openssl_library(void)
{
(void)SSL_library_init();

SSL_load_error_strings();

/* ERR_load_crypto_strings(); */

OPENSSL_config(NULL);

/* Include <openssl/opensslconf.h> to get this define */
#if defined (OPENSSL_THREADS)
fprintf(stdout, "Warning: thread locking is not implemented\n");
#endif
}</pre>

'''<tt>SSL_library_init</tt>''' performs initialization of <tt>libcrypto</tt> and <tt>libssl</tt>, and loads required algorithms. The documents state <tt>SSL_library_init</tt> always returns <tt>1</tt>, so its a useless return value.

'''<tt>SSL_load_error_strings</tt>''' loads error strings from both <tt>libcrypto</tt> and <tt>libssl</tt>. There's no need to call <tt>ERR_load_crypto_strings</tt>.

'''<tt>OpenSSL_add_ssl_algorithms</tt>''' is a <tt>#define</tt> for <tt>SSL_library_init</tt>, so the call is omitted.

'''<tt>OPENSSL_config</tt>''' may (or may not) be needed. Internally, <tt>OPENSSL_config</tt> is called based on a configuration options via <tt>OPENSSL_LOAD_CONF</tt>. If you are dynamically loading an engine specified in <tt>openssl.cnf</tt>, then you might need it so you should call it. That is, don't depend upon the OpenSSL library to call it for you.

If you are building a multi-threaded client, you should set the locking callbacks. See [https://www.openssl.org/docs/crypto/threads.html threads(3)] for details.

A detailed treatment of initialization can be found at [[Library Initialization]].

== Context Setup ==

The sample program uses '''<tt>SSLv23_method</tt>''' to create a context. '''<tt>SSLv23_method</tt>''' specifies that version negotiation will be used. Do not be confused by the name (it does NOT mean that only SSLv2 or SSLv3 will be used). The name is like that for historical reasons, and the function has been renamed to '''<tt>TLS_method</tt>''' in the forthcoming OpenSSL version 1.1.0. Using this method will negotiate the highest protocol version supported by both the server and the client. SSL/TLS versions currently supported by OpenSSL 1.0.2 are SSLv2, SSLv3, TLS1.0, TLS1.1 and TLS1.2.

The actual SSL and TLS protocols are further tuned through options. By using <tt>SSLv23_method</tt> (and removing the unwanted protocol versions with <tt>SSL_OP_NO_SSLv2</tt> and <tt>SSL_OP_NO_SSLv3</tt>), then you will effectively use TLS v1.0 and above, including TLS v1.2. You can also use <tt>SSL_OP_NO_TLSv1</tt> and <tt>SSL_OP_NO_TLSv1_1</tt> if you want to use the TLS 1.2 protocol only.

'''<tt>SSL_CTX_new</tt>''' uses the <tt>SSLv23_method</tt> method to create a new '''SSL/TLS context object'''. If you use, for example <tt>TLSv1_method</tt>, then you will only use TLS v1.0, and if you use <tt>TLSv1_1_method</tt> then you will only use TLS v1.1. Typically you should always use '''<tt>SSLv23_method</tt>''' in preference to the version specific methods.

OpenSSL 1.1.0 improves protocol selection by providing <tt>SSL_CTX_set_max_proto_version()</tt> and <tt>SSL_CTX_set_min_proto_version()</tt>. You no longer need to subtract unwanted options with <tt>SSL_OP_NO_SSLv2</tt> and <tt>SSL_OP_NO_SSLv3</tt>. Also see the [http://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_max_proto_version.html <tt>SSL_CTX_set_max_proto_version()</tt> and <tt>SSL_CTX_set_min_proto_version()</tt> man pages].

== Options (1) ==

After creating a context with <tt>SSLv23_method</tt> and <tt>SSL_CTX_new</tt>, the context object is tuned with the following functions:

* <tt>SSL_CTX_set_verify</tt>
* <tt>SSL_CTX_set_verify_depth</tt>
* <tt>SSL_CTX_set_options</tt>
* <tt>SSL_CTX_load_verify_locations</tt>

'''<tt>SSL_CTX_set_verify</tt>''' sets the <tt>SSL_VERIFY_PEER</tt> flag and the verify callback. This ensures the chain is verified according to [http://tools.ietf.org/html/rfc4158 RFC 4158] and Issuer and Subject information can be printed. If you don't want to perform custom processing (such as printing or checking), then don't set the callback. OpenSSL's default checking should be sufficient, so pass <tt>NULL</tt> to <tt>SSL_CTX_set_verify</tt>.

There is also a <tt>SSL_VERIFY_FAIL_IF_NO_PEER_CERT</tt> flag, but it is used for servers and has no effect on clients. If you accidentally use <tt>SSL_VERIFY_FAIL_IF_NO_PEER_CERT</tt>, then you chain will always verify when call <tt>SSL_get_verify_result</tt> because the flag is ignored for clients (essentially, 0 is passed for the flag which performs no verification).

'''<tt>SSL_CTX_set_verify_depth</tt>''' sets the chain depth to 4. Chain depth is fairly useless in practice.

'''<tt>SSL_CTX_set_options</tt>''' set the <tt>SSL_OP_ALL</tt>, <tt>SSL_OP_NO_SSLv2</tt>, <tt>SSL_OP_NO_SSLv3</tt>, <tt>SSL_OP_NO_COMPRESSION</tt> options. In essence, it takes all the bug fixes and work arounds for the various servers, removes the SSL protocols (leaving only TLS protocols), and removes compression. The remaining TLS protocols are TLS 1.0, TLS 1.1, and TLS 1.2.

'''<tt>SSL_CTX_load_verify_locations</tt>''' loads the certificate chain for the <tt>random.org</tt> site. The site's CA is Comodo, and the chain includes ''AddTrust External CA Root'', ''COMODO Certification Authority'', and ''COMODO Extended Validation Secure Server CA''. Though the chain is provided, only the single trust anchor is needed for validation. The additional intermediate certs are provided to show how to concatenate and load them.

The PEM format means the file is a concatenation of Base64 encoded certificates with the <tt>-----BEGIN CERTIFICATE-----</tt> prologue (and associated epilogue). If the server sends all certificates required to verify the chain (which it should), then only the ''AddTrust External CA Root'' certificate is needed.

The options set on the <tt>CTX*</tt> can be overridden on a per-connection basis by modifying the <tt>SSL*</tt> using <tt>SSL_set_verify</tt>, <tt>SSL_set_verify_depth</tt> and <tt>SSL_set_options</tt> (and friends).

== SSL BIO ==

The sample program uses BIOs for input and output. One BIO is used to connect to <tt>random.org</tt>, and a second BIO is used to print output to <tt>stdout</tt>.

'''<tt>BIO_new_ssl_connect</tt>''' creates a new BIO chain consisting of an SSL BIO (using ctx) followed by a connect BIO.

'''<tt>BIO_set_conn_hostname</tt>''' is used to set the hostname and port that will be used by the connection.

== Options (2) ==

'''<tt>BIO_get_ssl</tt>''' is used to fetch the '''SSL connection object''' created by <tt>BIO_new_ssl_connect</tt>. The connection object inherits from the context object, and can override the settings on the context. The connection object is tuned with the following functions:

* <tt>SSL_set_cipher_list</tt>
* <tt>SSL_set_tlsext_host_name</tt>

'''<tt>SSL_set_cipher_list</tt>''' sets the cipher list. The list prefers elliptic curves, ephemeral [Diffie-Hellman], AES and SHA. It also removes NULL authentication methods and ciphers; and removes medium-security, low-security and export-grade security ciphers, such as 40-bit RC2. If desired, you could set the options on the context with <tt>SSL_CTX_set_cipher_list</tt>.

'''<tt>SSL_set_tlsext_host_name</tt>''' uses the TLS SNI extension to set the hostname. If you are connecting to a Server Name Indication-aware server (such as Apache with name-based virtual hosts or IIS 8.0), then you will receive the proper certificate during the handshake.

== Cipher Suites ==

[[File:cipher-suites.png|thumb|right|Wireshark and ClientHello]] According to <tt>openssl ciphers ALL</tt>, there are just over 110 cipher suites available. Each cipher suite takes 2 bytes in the <tt>ClientHello</tt>, so advertising every cipher suite available at the client is going to cause a big <tt>ClientHello</tt> (or bigger then needed to get the job done). When using <tt>SSL_CTX_set_cipher_list</tt> or <tt>SSL_set_cipher_list</tt> with the string <tt>"HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4"</tt>, you'll cut the number of cipher suites down to about 45. If you know the server '''does not''' support DSA, then you can add <tt>"!DSS"</tt> and reduce the list further by about 7. And removing RSA key transport (<tt>"!kRSA"</tt>) removes another 9 more (this is a good practice because it uses ephemeral key exchanges which provide forward secrecy). Advertising 35 or so ciphers saves about 160 bytes in the <tt>ClientHello</tt>.

Better, pick 16 or 20 ciphers you want to support and advertise them. Order them so the GCM mode ciphers from TLS 1.2 are listed first, and the AES-SHA ciphers from TLS 1.0 are listed last. Though TLS 1.0 should be avoided, its probably needed for interop because only about [https://www.trustworthyinternet.org/ssl-pulse/ half the servers on the internet support TLS 1.2]. If you control the server, then it should be offering TLS 1.2 and clients only need to advertise AEAD ciphers like AES/GCM or Camellia/GCM.

Keeping the <tt>ClientHello</tt> small is important for older F5 and IronPort devices. Apparently, the devices used fixed sized buffers and choke on large <tt>ClientHello</tt>'s. In fact, a "large hello" was the cause of the TLS padding bug on IronPort devices. See [http://www.ietf.org/mail-archive/web/tls/current/msg12145.html TLS padding breaks ironport] on the TLS mailing list for details.

== Connection ==

[[File:bio-fetch-3.png|thumb|right|Wireshark and TLS versions]] After setting the connection object options, the sample connects to the site and negotiates a secure channel.

* <tt>BIO_do_connect</tt>
* <tt>BIO_do_handshake</tt>

'''<tt>BIO_do_connect</tt>''' performs the name lookup for the host and standard TCP/IP three way handshake.

'''<tt>BIO_do_handshake</tt>''' performs the SSL/TLS handshake. If you set a callback with <tt>SSL_CTX_set_verify</tt> or <tt>SSL_set_verify</tt>, then you callback will be invoked for each certificate in the chain used during the execution of the protocol.

The Wireshark packet capture to the right shows the TLS handshake with the SNI extension encountered during the execution of <tt>BIO_do_handshake</tt>. OpenSSL 1.0.1e advertises TLSv1.2 as the highest protocol level in its <tt>ClientHello</tt>.

== Callback ==

OpenSSL provides the ability for an application to interact with the chain validation by way of a callback. Normally, most application don't need to use it since the default OpenSSL behavior is usually adequate. In the callback, you can pass the <tt>preverify</tt> result back to the library (leaving library behavior unchanged), or you can modify the result to account for a specific issue that your software should address (override default behavior). If you don't need to interact with chain validation, then don't set the callback.

The example program returned the <tt>preverify</tt> result to the library and just printed information about the certificate in the chain. It did so by using <tt>SSL_CTX_set_verify</tt> with <tt>SSL_VERIFY_PEER</tt> and the <tt>verify_callback</tt>.

<pre>int verify_callback(int preverify, X509_STORE_CTX* x509_ctx)
{
int depth = X509_STORE_CTX_get_error_depth(x509_ctx);
int err = X509_STORE_CTX_get_error(x509_ctx);

X509* cert = X509_STORE_CTX_get_current_cert(x509_ctx);
X509_NAME* iname = cert ? X509_get_issuer_name(cert) : NULL;
X509_NAME* sname = cert ? X509_get_subject_name(cert) : NULL;

print_cn_name("Issuer (cn)", iname);
print_cn_name("Subject (cn)", sname);

if(depth == 0) {
/* If depth is 0, its the server's certificate. Print the SANs too */
print_san_name("Subject (san)", cert);
}

return preverify;
}</pre>

The OpenSSL library will pass in the value of its preliminary checking of the certificate through <tt>preverify</tt>. '''If''' you always return <tt>1</tt> regardless of the value of <tt>preverify</tt> or the actual result of your processing, then <tt>SSL_get_verify_result</tt> will always return <tt>X509_V_OK</tt>. That's probably a bad idea for production software.

If you don't need to perform special processing on the chain, then you should forgo the <tt>verify_callback</tt> altogether by supplying <tt>NULL</tt> to <tt>SSL_CTX_set_verify</tt>:

<pre>SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);</pre>

== Verification ==

You use one of two verification procedures, depending on the version of OpenSSL you are using. The change occurs at OpenSSL 1.1.0 because 1.1.0 (and above) implements hostname verification that 1.0.2 (and below) lacked. Painting with a broad brush, minimal checking includes: (1) confirm the server has a certificate, (2) confirm the certificate chain verifies back to a trusted root, and (3) confirm the name of the host matches a hostname listed in the server's certificate.

In the end, its probably better to ignore PKI and just use Public Key Pinning (or Certificate Pinning) when a pre-exisiting relationship exists; or use a Perspectives-like system or a Trust-On-First-Use (TOFU) system when there's no ''a priori'' relationship (similar to SSH's <tt>StrictHostkeyChecking</tt> option). See Peter Gutmann's [https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf Engineering Security] for details of a security diversification strategy (Chapter 4, starting on page 292).

You usually don't perform revocation in real time because it essentially creates a denial of service on your application. That is, your app will hang while downloading a multi-megabyte CRL or contacts a missing OCSP responder. For a detailed treatment of problems with PKI and Revocation, see Peter Gutmann's [https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf Engineering Security] (Chapters 1 and 8).

=== OpenSSL 1.0.2 ===

OpenSSL 1.0.2 and below requires at least three checks. These versions of OpenSSL do ''not'' perform hostname validation and the API user must perform it.

==== Server Certificate ====

You must confirm the server provided a certificate. This is because a server might be misconfigured, or the client and server used Anonymous Diffie-Hellman. You do so as follows:

<pre>X509* cert = SSL_get_peer_certificate(ssl);
if(cert) { X509_free(cert); }
if(NULL == cert) handleFailure();</pre>

If the server has a certificate, then <tt>SSL_get_peer_certificate</tt> will return a non-NULL value. You don't really need the certificate, so its <tt>free</tt>'d immediately.

==== Certificate Chain ====

You must confirm the server's certificate chains back to a trusted root, and all the certificates in the chain are valid. You do so as follows:

<pre>long res = SSL_get_verify_result(ssl);
if(!(X509_V_OK == res)) handleFailure();</pre>

<tt>SSL_get_verify_result</tt> returns the result of verifying the chain. See the earlier warning on doing the wrong thing in the verification callback.

==== Certificate Names ====

You must confirm a match between the hostname you contacted and the hostnames listed in the certificate. OpenSSL prior to 1.1.0 does not perform hostname verification, so you will have to perform the checking yourself. The sample code does not offer code at the moment, so you will need to borrow it or implement it.

If you want to borrow the code, take a look at [http://curl.haxx.se/libcurl/ libcurl] and the verification procedure in source file <tt>ssluse.c</tt>. Another source is the C/C++ Secure Coding Guide and Section 10.8, [http://etutorials.org/Programming/secure+programming/Chapter+10.+Public+Key+Infrastructure/10.8+Adding+Hostname+Checking+to+Certificate+Verification/ Adding Hostname Checking to Certificate Verification]. If you implement the code for checking, the sample code shows you how to extract the Common Name (CN) and Subject Alternate Names (SAN) from the certificate in <tt>print_cn_name</tt> and <tt>print_san_name</tt>.

'''Note''': matching between the hostname (used in <tt>BIO_do_connect </tt>) and names in the certificate (from <tt>SSL_get_peer_certificate</tt>) must also be validated. For example, a certificate cannot claim to be wildcarded for <tt>*.com</tt>, <tt>*.net</tt>, or other Top Level Domains (TLDs). In addition to the TLDs, you also have to country level or ccTLDs, so it can't match <tt>*.us</tt>, <tt>*.cn</tt>, <tt>*.fed.us</tt>, <tt>*.公司.cn</tt> or similar levels either. Mozilla maintains a list of ccTLDs that are off limits at the [http://publicsuffix.org/ Public Suffix List], and there are currently 6136 entries on the list.

== Program Output ==

After all this musing, here's the lousy output you get when running the program:

{| align="center"
| [[File:bio-fetch-1.png|350px|Figure 1: Chain Output]]
|    
| [[File:bio-fetch-2.png|350px|Figure 2: Server Response]]
|}

== Session Reuse ==

According to Viktor Dukhovni at [http://mta.openssl.org/pipermail/openssl-users/2016-September/004564.html Possible to control session reuse from the client]:

<pre>> For performance testing purposes, I would like to turn off session
> reuse in the (homegrown) client I use for testing. Is there a function
> in the openssl library to do it?
>
> I tried googling for "openssl client don't send session id" but I didn't
> find anything useful.

Just do nothing. Client sessions are not reused unless you explicitly
arrange for reuse of a session by calling SSL_set_session() before
SSL_connect(). If you're trying to avoid wasting memory on storing
client-side sessions that you'll never reuse then this may help:

SSL_CTX_set_session_cache_mode(client_ctx, SSL_SESS_CACHE_OFF);

but note this is also the default state, so is also not needed unless
some other code has explicitly enabled client-side caching of sessions.

Only the server-side cache is enabled by default.</pre>

== Session Tickets ==

Session tickets are specified in [http://www.ietf.org/rfc/rfc5077.txt RFC 5077]. You can disable session tickets with <tt>SSL_OP_NO_TICKET</tt>:

<pre>const long flags = SSL_OP_NO_SSLv3 | ... | SSL_OP_NO_TICKET;
SSL_CTX_set_options(ctx, flags);</pre>

== 0-RTT ==

0-RTT is specified in XXX (TODO). 0-RTT allows an application to immediately resume a previous session at the expense of consuming unauthenticated data. You should avoid 0-RTT if possible. In fact, an organization's data security policy may not allow it for some higher data sensitivity levels.

Care should be taken if enabling 0-RTT at the client because a number of protections must be enabled at the server. Additionally, some of the protections are required higher up in the stack, outside of the secure socket layer. Below is a list of potential problems from [http://www.ietf.org/mail-archive/web/tls/current/msg15594.html 0-RTT and Anti-Replay] and [http://www.ietf.org/mail-archive/web/tls/current/msg23561.html Closing on 0-RTT] on the IETF TLS working group mailing list.

* 0-RTT without stateful anti-replay allows for very high number of replays, breaking rate limiting systems, even high-performance ones, resulting in an opening for DDoS attacks.

* 0-RTT without stateful anti-replay allows for very high number of replays, allowing exploiting timing side channels for information leakage. Very few if any applications are engineered to mitigate or eliminate such side channels.

* 0-RTT without global anti-replay allows leaking information from the 0-RTT data via cache timing attacks. HTTP GET URLs sent to CDNs are especially vulnerable.

* 0-RTT without global anti-replay allows non-idempotent actions contained in 0-RTT data to be repeated potentially lots of times. Abuse of HTTP GET for non-idempotent actions is fairly common.

* 0-RTT allows easily reordering request with re-transmission from the client. This can lead to various unexpected application behavior if possibility of such reordering is not taken into account. "Eventually consistent" datastores are especially vulnerable.

* 0-RTT exporters are not safe for authentication unless the server does global anti-replay on 0-RTT.

== Downloads ==

[[Media:openssl-bio-fetch.tar.gz|openssl-bio-fetch.tar.gz]] - The program and Makefile used for this wiki page.

Talk:Simple TLS Client

2022-04-24T20:11:05Z

Philippe lhardy:

This page should probably redirect to [[SSL/TLS Client]].

If you want to direct people to OpenSSL's demo code, then mention it on the SSL/TLS Client page.

[[User:Jwalton|Jwalton]] ([[User talk:Jwalton|talk]]) 18:50, 24 April 2022 (UTC)

This page is referenced in Main Page 'Usage and Programming' and is counter part of [[Simple_TLS_Server]] for Client case with Category Example an C code.
I will reference it from [[SSL/TLS Client]].

[[User:Philippe_lhardy]]

Simple TLS Client

2022-04-24T20:05:58Z

Philippe lhardy:

You may find an up to date example within repository demos/sslecho together with server.

[[Category:Examples]]
[[Category:C level]]

Simple TLS Client

2022-04-24T16:26:44Z

Philippe lhardy: reference to demos/sslecho

You may find an up to date example within repository demos/sslecho together with server.

Simple TLS Server

2022-04-24T16:24:42Z

Philippe lhardy: add reference to demo/sslecho

You may find an up to date example within repository demos/sslecho.

The code below is a complete implementation of a minimal TLS server. The first thing we do is create an ''SSL_CTX'' or SSL context. This is created using the ''TLS_server_method'' which creates a server that will negotiate the highest version of SSL/TLS supported by the client it is connecting to. The context is then configured by specifying the certificate and private key to use.

Next we perform some normal socket programming and create a new server socket, there's nothing OpenSSL specific about this code. Whenever we get a new connection we call ''accept'' as normal. To handle the TLS we create a new ''SSL'' structure, this holds the information related to this particular connection. We use ''SSL_set_fd'' to tell openssl the file descriptor to use for the communication. In this example, we call ''SSL_accept'' to handle the server side of the TLS handshake, then use ''SSL_write()'' to send our message. Finally we clean up the various structures.

<pre>

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <openssl/ssl.h>
#include <openssl/err.h>

int create_socket(int port)
{
int s;
struct sockaddr_in addr;

addr.sin_family = AF_INET;
addr.sin_port = htons(port);
addr.sin_addr.s_addr = htonl(INADDR_ANY);

s = socket(AF_INET, SOCK_STREAM, 0);
if (s < 0) {
perror("Unable to create socket");
exit(EXIT_FAILURE);
}

if (bind(s, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
perror("Unable to bind");
exit(EXIT_FAILURE);
}

if (listen(s, 1) < 0) {
perror("Unable to listen");
exit(EXIT_FAILURE);
}

return s;
}

SSL_CTX *create_context()
{
const SSL_METHOD *method;
SSL_CTX *ctx;

method = TLS_server_method();

ctx = SSL_CTX_new(method);
if (!ctx) {
perror("Unable to create SSL context");
ERR_print_errors_fp(stderr);
exit(EXIT_FAILURE);
}

return ctx;
}

void configure_context(SSL_CTX *ctx)
{
/* Set the key and cert */
if (SSL_CTX_use_certificate_file(ctx, "cert.pem", SSL_FILETYPE_PEM) <= 0) {
ERR_print_errors_fp(stderr);
exit(EXIT_FAILURE);
}

if (SSL_CTX_use_PrivateKey_file(ctx, "key.pem", SSL_FILETYPE_PEM) <= 0 ) {
ERR_print_errors_fp(stderr);
exit(EXIT_FAILURE);
}
}

int main(int argc, char **argv)
{
int sock;
SSL_CTX *ctx;

ctx = create_context();

configure_context(ctx);

sock = create_socket(4433);

/* Handle connections */
while(1) {
struct sockaddr_in addr;
unsigned int len = sizeof(addr);
SSL *ssl;
const char reply[] = "test\n";

int client = accept(sock, (struct sockaddr*)&addr, &len);
if (client < 0) {
perror("Unable to accept");
exit(EXIT_FAILURE);
}

ssl = SSL_new(ctx);
SSL_set_fd(ssl, client);

if (SSL_accept(ssl) <= 0) {
ERR_print_errors_fp(stderr);
} else {
SSL_write(ssl, reply, strlen(reply));
}

SSL_shutdown(ssl);
SSL_free(ssl);
close(client);
}

close(sock);
SSL_CTX_free(ctx);
}

</pre>

== Session Reuse ==

According to Viktor Dukhovni at [http://mta.openssl.org/pipermail/openssl-users/2016-September/004564.html Possible to control session reuse from the client]:

<pre>> For performance testing purposes, I would like to turn off session
> reuse in the (homegrown) client I use for testing. Is there a function
> in the openssl library to do it?
>
> I tried googling for "openssl client don't send session id" but I didn't
> find anything useful.

Just do nothing. Client sessions are not reused unless you explicitly
arrange for reuse of a session by calling SSL_set_session() before
SSL_connect(). If you're trying to avoid wasting memory on storing
client-side sessions that you'll never reuse then this may help:

SSL_CTX_set_session_cache_mode(client_ctx, SSL_SESS_CACHE_OFF);

but note this is also the default state, so is also not needed unless
some other code has explicitly enabled client-side caching of sessions.

Only the server-side cache is enabled by default.</pre>

== 0-RTT ==

0-RTT is specified in XXX (TODO). 0-RTT allows an application to immediately resume a previous session at the expense of consuming unauthenticated data. You should avoid 0-RTT if possible. In fact, an organization's data security policy may not allow it for some higher data sensitivity levels.

Care should be taken if enabling 0-RTT at the server because a number of protections must be enabled. Additionally, some of the protections are required higher up in the stack, outside of the secure socket layer. Below is a list of potential problems from [http://www.ietf.org/mail-archive/web/tls/current/msg23561.html Closing on 0-RTT] on the IETF TLS working group mailing list.

* 0-RTT without stateful anti-replay allows for very high number of replays, breaking rate limiting systems, even high-performance ones, resulting in an opening for DDoS attacks.

* 0-RTT without stateful anti-replay allows for very high number of replays, allowing exploiting timing side channels for information leakage. Very few if any applications are engineered to mitigate or eliminate such side channels.

* 0-RTT without global anti-replay allows leaking information from the 0-RTT data via cache timing attacks. HTTP GET URLs sent to CDNs are especially vulnerable.

* 0-RTT without global anti-replay allows non-idempotent actions contained in 0-RTT data to be repeated potentially lots of times. Abuse of HTTP GET for non-idempotent actions is fairly common.

* 0-RTT allows easily reordering request with re-transmission from the client. This can lead to various unexpected application behavior if possibility of such reordering is not taken into account. "Eventually consistent" datastores are especially vulnerable.

* 0-RTT exporters are not safe for authentication unless the server does global anti-replay on 0-RTT.

[[Category:Examples]]
[[Category:C level]]

Talk:Command Line Utilities

2020-06-14T15:44:34Z

Philippe lhardy:

== Pretty significant rewrite ==

I noticed a lot of the information on the page was essentially a print out of the program help menu, so I thought it would be more beneficial to provide a basic introduction to the command-line utilities in tutorial form, with links to the official documentation. It isn't finished, as there are a lot of topics I didn't cover (certificates being a significant topic I did not cover), but because of the magnitude of the changes, I thought it best to stop here and get feedback on the changes. I'm brand-new to the project and I'm excited contribute in a meaningful way, so please if there is any wrong information, the style is off, etc., please do pass that along.

This rewrite is essentially a reformatting of the previous version, with a lot of additional explanations from the perldocs. The bulk of the changes come from the removing of the old code samples, which were essentially just the helps menus, and the addition of code examples which again come primarily from the perldocs. There's also a table with all of the standard commands which link to their respective manpage on the main openssl site. I thought this was better because now we only have to update one set of documentation, which itself is automatically generated from the pod files.

--[[User:Jflopezfernandez|Jflopezfernandez]] ([[User talk:Jflopezfernandez|talk]]) 03:35, 30 July 2019 (UTC)

: This new style page looks great!! Please continue with it.
: A point to note about the ec key generation stuff. It is not necessary to first create an ec params file. It is simpler just to generate the key directly using genpkey and passing the pkeyopt "ec_paramgen_curve". See the man page for further details.
: --[[User:Matt|Matt]] ([[User talk:Matt|talk]]) 08:27, 30 July 2019 (UTC)

:: Awesome, I'll go ahead and add that in, thanks for the heads up. I'm glad you like the change; I was pretty nervous about it since it was a pretty big change and I'm still brand-new.
:: --[[User:Jflopezfernandez|Jflopezfernandez]] ([[User talk:Jflopezfernandez|talk]]) 15:27, 30 July 2019 (UTC)

::: During this rewrite a comment about base64 usage 64 characters per line limit and -A usage was lost
::: i found it while rereading one old answer i did on stack overflow see https://askubuntu.com/questions/178521/how-can-i-decode-a-base64-string-from-the-command-line reference )
::: --[[User:Philippe lhardy|Philippe lhardy]] ([[User talk:Philippe lhardy|talk]]) 15:43, 14 June 2020 (UTC)

Talk:Command Line Utilities

2020-06-14T15:43:38Z

Philippe lhardy:

== Pretty significant rewrite ==

I noticed a lot of the information on the page was essentially a print out of the program help menu, so I thought it would be more beneficial to provide a basic introduction to the command-line utilities in tutorial form, with links to the official documentation. It isn't finished, as there are a lot of topics I didn't cover (certificates being a significant topic I did not cover), but because of the magnitude of the changes, I thought it best to stop here and get feedback on the changes. I'm brand-new to the project and I'm excited contribute in a meaningful way, so please if there is any wrong information, the style is off, etc., please do pass that along.

This rewrite is essentially a reformatting of the previous version, with a lot of additional explanations from the perldocs. The bulk of the changes come from the removing of the old code samples, which were essentially just the helps menus, and the addition of code examples which again come primarily from the perldocs. There's also a table with all of the standard commands which link to their respective manpage on the main openssl site. I thought this was better because now we only have to update one set of documentation, which itself is automatically generated from the pod files.

--[[User:Jflopezfernandez|Jflopezfernandez]] ([[User talk:Jflopezfernandez|talk]]) 03:35, 30 July 2019 (UTC)

: This new style page looks great!! Please continue with it.
: A point to note about the ec key generation stuff. It is not necessary to first create an ec params file. It is simpler just to generate the key directly using genpkey and passing the pkeyopt "ec_paramgen_curve". See the man page for further details.
: --[[User:Matt|Matt]] ([[User talk:Matt|talk]]) 08:27, 30 July 2019 (UTC)

:: Awesome, I'll go ahead and add that in, thanks for the heads up. I'm glad you like the change; I was pretty nervous about it since it was a pretty big change and I'm still brand-new.
:: --[[User:Jflopezfernandez|Jflopezfernandez]] ([[User talk:Jflopezfernandez|talk]]) 15:27, 30 July 2019 (UTC)

::: During this rewrite a comment about 64 characters per line limit and -A usage was lost
::: i found it while rereading one old answer i did on stack overflow see https://askubuntu.com/questions/178521/how-can-i-decode-a-base64-string-from-the-command-line reference )
::: --[[User:Philippe lhardy|Philippe lhardy]] ([[User talk:Philippe lhardy|talk]]) 15:43, 14 June 2020 (UTC)

Mailing Lists

2017-08-28T19:45:49Z

Philippe lhardy:

There are four mailing lists, see [https://www.openssl.org/community/mailinglists.html)

Base64

2015-11-22T17:05:50Z

Philippe lhardy: /* base64 uses PEM 80 characters per line */

Encode binary information 8 bits into ASCII.

This is PEM base encode, it exists other base64 encoding scheme like this used by crypt.

== Algorithm ==

3 x 8 bits binary are concatenated to form a 24bits word that is split in 4 x 6bits each being translating into an ascii value using a character ordered in following list :

<pre>
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0000000000111111111122222222223333333333444444444455555555556666
0123456789012345678901234567890123456789012345678901234567890123
</pre>

[what makes 26 * 2 + 10 + 2 = 64 values]

Since it encodes by group of 3 bytes, when last group of 3 bytes miss one byte then = is used, when it miss 2 bytes then == is used for padding.

== Openssl command ==

base64 or -enc base64 can be used to decode lines see [[Command_Line_Utilities]]

== EVP API ==

crypto/evp/encode.c
crypto/evp/bio_b64.C

=== WARNINGS ===

=== other unsupported base64 scheme ===

Warning crypt() password encryption function uses another base64 scheme which is not the openssl base64 one. :

<pre>
./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0000000000111111111122222222223333333333444444444455555555556666
0123456789012345678901234567890123456789012345678901234567890123
</pre>

=== base64 uses PEM 80 characters per line ===

Base64 itself does not impose a line split, but openssl uses it in PEM context hence enforce that base64 content is splitted by lines with a maximum of 80 characters.

With C code it is possible to ask to disregard lines breaks : BIO_set_flags(d,BIO_FLAGS_BASE64_NO_NL);

[[Category:Encoding]]

Base64

2015-11-22T17:04:06Z

Philippe lhardy:

DER

2015-11-22T14:26:15Z

Philippe lhardy: /* sample */

DER is a binary format for data structures described by ASN.1.

by example x509 is described in ASN1 and encoded in DER. It exists other encoding formats for ASN.1 but DER is the one choose for security since ther is only one possible encoding given a ASN.1. encoding ( what is not the case for BER used in ldap by example ).

== command ==

openssl ''asn1parse'' is the command to display internal structure of a DER document.

[[Category:Shell level]]

== sample ==

When using i2d_X509_fp(FILE * outcert, X509 * x509_cert) file result is raw DER encoded value of X509 Certificate.

C code to dump a X509 into DER format :
<pre>
void dump_x509_cert(X509* x509_cert)
{
const char * dumpcertfile = "dumpcertfile";
if (dumpcertfile != NULL)
{
FILE * outcert = fopen(dumpcertfile,"w");
if ( outcert )
{
i2d_X509_fp(outcert, x509_cert);
fclose(outcert);
}
else
{
fprintf(stderr,"[ERROR] Can't create %s file\n", dumpcerfile);
}
}
}
</pre>

to view content :

openssl asn1parse -in dumpcertfile -inform DER

<pre>
0:d=0 hl=4 l= 981 cons: SEQUENCE
4:d=1 hl=4 l= 701 cons: SEQUENCE
8:d=2 hl=2 l= 3 cons: cont [ 0 ]
10:d=3 hl=2 l= 1 prim: INTEGER :02
13:d=2 hl=2 l= 4 prim: INTEGER :5631333F
19:d=2 hl=2 l= 13 cons: SEQUENCE
21:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption
32:d=3 hl=2 l= 0 prim: NULL
34:d=2 hl=2 l= 127 cons: SEQUENCE
36:d=3 hl=2 l= 11 cons: SET
38:d=4 hl=2 l= 9 cons: SEQUENCE
40:d=5 hl=2 l= 3 prim: OBJECT :countryName
45:d=5 hl=2 l= 2 prim: PRINTABLESTRING :FR
49:d=3 hl=2 l= 28 cons: SET
51:d=4 hl=2 l= 26 cons: SEQUENCE
53:d=5 hl=2 l= 3 prim: OBJECT :commonName
58:d=5 hl=2 l= 19 prim: PRINTABLESTRING :pavilionartlogiciel
79:d=3 hl=2 l= 28 cons: SET
81:d=4 hl=2 l= 26 cons: SEQUENCE
83:d=5 hl=2 l= 3 prim: OBJECT :organizationName
88:d=5 hl=2 l= 19 prim: PRINTABLESTRING :pavilionartlogiciel
109:d=3 hl=2 l= 16 cons: SET
111:d=4 hl=2 l= 14 cons: SEQUENCE
113:d=5 hl=2 l= 3 prim: OBJECT :organizationalUnitName
118:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Unknown
127:d=3 hl=2 l= 16 cons: SET
129:d=4 hl=2 l= 14 cons: SEQUENCE
131:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
136:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Unknown
145:d=3 hl=2 l= 16 cons: SET
147:d=4 hl=2 l= 14 cons: SEQUENCE
149:d=5 hl=2 l= 3 prim: OBJECT :localityName
154:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Unknown
163:d=2 hl=2 l= 34 cons: SEQUENCE
165:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20151028204239Z
182:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20251025204239Z
199:d=2 hl=2 l= 127 cons: SEQUENCE
201:d=3 hl=2 l= 11 cons: SET
203:d=4 hl=2 l= 9 cons: SEQUENCE
205:d=5 hl=2 l= 3 prim: OBJECT :countryName
210:d=5 hl=2 l= 2 prim: PRINTABLESTRING :FR
214:d=3 hl=2 l= 28 cons: SET
216:d=4 hl=2 l= 26 cons: SEQUENCE
218:d=5 hl=2 l= 3 prim: OBJECT :commonName
223:d=5 hl=2 l= 19 prim: PRINTABLESTRING :pavilionartlogiciel
244:d=3 hl=2 l= 28 cons: SET
246:d=4 hl=2 l= 26 cons: SEQUENCE
248:d=5 hl=2 l= 3 prim: OBJECT :organizationName
253:d=5 hl=2 l= 19 prim: PRINTABLESTRING :pavilionartlogiciel
274:d=3 hl=2 l= 16 cons: SET
276:d=4 hl=2 l= 14 cons: SEQUENCE
278:d=5 hl=2 l= 3 prim: OBJECT :organizationalUnitName
283:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Unknown
292:d=3 hl=2 l= 16 cons: SET
294:d=4 hl=2 l= 14 cons: SEQUENCE
296:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
301:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Unknown
310:d=3 hl=2 l= 16 cons: SET
312:d=4 hl=2 l= 14 cons: SEQUENCE
314:d=5 hl=2 l= 3 prim: OBJECT :localityName
319:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Unknown
328:d=2 hl=4 l= 290 cons: SEQUENCE
332:d=3 hl=2 l= 13 cons: SEQUENCE
334:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption
345:d=4 hl=2 l= 0 prim: NULL
347:d=3 hl=4 l= 271 prim: BIT STRING
622:d=2 hl=2 l= 85 cons: cont [ 3 ]
624:d=3 hl=2 l= 83 cons: SEQUENCE
626:d=4 hl=2 l= 12 cons: SEQUENCE
628:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints
633:d=5 hl=2 l= 1 prim: BOOLEAN :255
636:d=5 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000
640:d=4 hl=2 l= 19 cons: SEQUENCE
642:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Extended Key Usage
647:d=5 hl=2 l= 12 prim: OCTET STRING [HEX DUMP]:300A06082B06010505070301
661:d=4 hl=2 l= 15 cons: SEQUENCE
663:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage
668:d=5 hl=2 l= 1 prim: BOOLEAN :255
671:d=5 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:0303072000
678:d=4 hl=2 l= 29 cons: SEQUENCE
680:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Identifier
685:d=5 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:0414304610060805E69AE14F84CC366012C0EB9E3D99
709:d=1 hl=2 l= 13 cons: SEQUENCE
711:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption
722:d=2 hl=2 l= 0 prim: NULL
724:d=1 hl=4 l= 257 prim: BIT STRING
</pre>

since it is a X509 certificate the best way to view content is

openssl x509 -in dumpcertfile -inform DER -text

[[Category:Encoding]]

DER

2015-11-22T14:24:46Z

Philippe lhardy: some sample

DER is a binary format for data structures described by ASN.1.

by example x509 is described in ASN1 and encoded in DER. It exists other encoding formats for ASN.1 but DER is the one choose for security since ther is only one possible encoding given a ASN.1. encoding ( what is not the case for BER used in ldap by example ).

== command ==

openssl ''asn1parse'' is the command to display internal structure of a DER document.

[[Category:Shell level]]

== sample ==

When using i2d_X509_fp(FILE * outcert, X509 * x509_cert) file result is raw DER encoded value of X509 Certificate.

C code to dump a X509 into DER format :
<pre>
void dump_x509_cert(X509* x509_cert)
{
const char * dumpcertfile = "dumpcertfile";
if (dumpcertfile != NULL)
{
FILE * outcert = fopen(dumpcertfile,"w");
if ( outcert )
{
i2d_X509_fp(outcert, x509_cert);
fclose(outcert);
}
else
{
fprintf(stderr,"[ERROR] Can't create server.cert file\n");
}
}
}
</pre>

to view content :

openssl asn1parse -in dumpcertfile -inform DER

<pre>
0:d=0 hl=4 l= 981 cons: SEQUENCE
4:d=1 hl=4 l= 701 cons: SEQUENCE
8:d=2 hl=2 l= 3 cons: cont [ 0 ]
10:d=3 hl=2 l= 1 prim: INTEGER :02
13:d=2 hl=2 l= 4 prim: INTEGER :5631333F
19:d=2 hl=2 l= 13 cons: SEQUENCE
21:d=3 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption
32:d=3 hl=2 l= 0 prim: NULL
34:d=2 hl=2 l= 127 cons: SEQUENCE
36:d=3 hl=2 l= 11 cons: SET
38:d=4 hl=2 l= 9 cons: SEQUENCE
40:d=5 hl=2 l= 3 prim: OBJECT :countryName
45:d=5 hl=2 l= 2 prim: PRINTABLESTRING :FR
49:d=3 hl=2 l= 28 cons: SET
51:d=4 hl=2 l= 26 cons: SEQUENCE
53:d=5 hl=2 l= 3 prim: OBJECT :commonName
58:d=5 hl=2 l= 19 prim: PRINTABLESTRING :pavilionartlogiciel
79:d=3 hl=2 l= 28 cons: SET
81:d=4 hl=2 l= 26 cons: SEQUENCE
83:d=5 hl=2 l= 3 prim: OBJECT :organizationName
88:d=5 hl=2 l= 19 prim: PRINTABLESTRING :pavilionartlogiciel
109:d=3 hl=2 l= 16 cons: SET
111:d=4 hl=2 l= 14 cons: SEQUENCE
113:d=5 hl=2 l= 3 prim: OBJECT :organizationalUnitName
118:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Unknown
127:d=3 hl=2 l= 16 cons: SET
129:d=4 hl=2 l= 14 cons: SEQUENCE
131:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
136:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Unknown
145:d=3 hl=2 l= 16 cons: SET
147:d=4 hl=2 l= 14 cons: SEQUENCE
149:d=5 hl=2 l= 3 prim: OBJECT :localityName
154:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Unknown
163:d=2 hl=2 l= 34 cons: SEQUENCE
165:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20151028204239Z
182:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20251025204239Z
199:d=2 hl=2 l= 127 cons: SEQUENCE
201:d=3 hl=2 l= 11 cons: SET
203:d=4 hl=2 l= 9 cons: SEQUENCE
205:d=5 hl=2 l= 3 prim: OBJECT :countryName
210:d=5 hl=2 l= 2 prim: PRINTABLESTRING :FR
214:d=3 hl=2 l= 28 cons: SET
216:d=4 hl=2 l= 26 cons: SEQUENCE
218:d=5 hl=2 l= 3 prim: OBJECT :commonName
223:d=5 hl=2 l= 19 prim: PRINTABLESTRING :pavilionartlogiciel
244:d=3 hl=2 l= 28 cons: SET
246:d=4 hl=2 l= 26 cons: SEQUENCE
248:d=5 hl=2 l= 3 prim: OBJECT :organizationName
253:d=5 hl=2 l= 19 prim: PRINTABLESTRING :pavilionartlogiciel
274:d=3 hl=2 l= 16 cons: SET
276:d=4 hl=2 l= 14 cons: SEQUENCE
278:d=5 hl=2 l= 3 prim: OBJECT :organizationalUnitName
283:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Unknown
292:d=3 hl=2 l= 16 cons: SET
294:d=4 hl=2 l= 14 cons: SEQUENCE
296:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
301:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Unknown
310:d=3 hl=2 l= 16 cons: SET
312:d=4 hl=2 l= 14 cons: SEQUENCE
314:d=5 hl=2 l= 3 prim: OBJECT :localityName
319:d=5 hl=2 l= 7 prim: PRINTABLESTRING :Unknown
328:d=2 hl=4 l= 290 cons: SEQUENCE
332:d=3 hl=2 l= 13 cons: SEQUENCE
334:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption
345:d=4 hl=2 l= 0 prim: NULL
347:d=3 hl=4 l= 271 prim: BIT STRING
622:d=2 hl=2 l= 85 cons: cont [ 3 ]
624:d=3 hl=2 l= 83 cons: SEQUENCE
626:d=4 hl=2 l= 12 cons: SEQUENCE
628:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints
633:d=5 hl=2 l= 1 prim: BOOLEAN :255
636:d=5 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000
640:d=4 hl=2 l= 19 cons: SEQUENCE
642:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Extended Key Usage
647:d=5 hl=2 l= 12 prim: OCTET STRING [HEX DUMP]:300A06082B06010505070301
661:d=4 hl=2 l= 15 cons: SEQUENCE
663:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage
668:d=5 hl=2 l= 1 prim: BOOLEAN :255
671:d=5 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:0303072000
678:d=4 hl=2 l= 29 cons: SEQUENCE
680:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Identifier
685:d=5 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:0414304610060805E69AE14F84CC366012C0EB9E3D99
709:d=1 hl=2 l= 13 cons: SEQUENCE
711:d=2 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption
722:d=2 hl=2 l= 0 prim: NULL
724:d=1 hl=4 l= 257 prim: BIT STRING
</pre>

since it is a X509 certificate the best way to view content is

openssl x509 -in dumpcertfile -inform DER -text

[[Category:Encoding]]

File:BIO f md filter.png

2015-10-18T20:35:31Z

Philippe lhardy: Graphical Artwork extracted from a future presenation. I created it, use at your will.

Graphical Artwork extracted from a future presenation.
I created it, use at your will.

Base64

2015-10-17T11:34:56Z

Philippe lhardy: openssl base64 specificities

Encode binary information 8 bits into ASCII.

This is PEM base encode, it exists other base64 encoding scheme like this uses by crypt.

== Algorithm ==

3 x 8 bits binary are concatenated to form a 24bits word that is split in 4 x 6bits each being translating into an ascii value using a character ordered in following list :

<pre>
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0000000000111111111122222222223333333333444444444455555555556666
0123456789012345678901234567890123456789012345678901234567890123
</pre>

[what makes 26 * 2 + 10 + 2 = 64 values]

Since it encodes by group of 3 bytes, when last group of 3 bytes miss one byte then = is used, when it miss 2 bytes then == is used for padding.

== Openssl command ==

base64 or -enc base64 can be used to decode lines see [[Command_Line_Utilities]]

== EVP API ==

crypto/evp/encode.c
crypto/evp/bio_b64.C

=== WARNINGS ===

=== other unsupported base64 scheme ===

Warning crypt() password encryption function uses another base64 scheme which is not the openssl base64 one. :

<pre>
./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0000000000111111111122222222223333333333444444444455555555556666
0123456789012345678901234567890123456789012345678901234567890123
</pre>

=== base64 uses PEM 80 characters per line ===

Base64 itself does not impose a line split, but openssl uses it in PEM context hence enforce that base64 content is splitted by lines with a maximum of 80 characters.

[[Category:Encoding]]

History And People

2015-10-14T19:31:53Z

Philippe lhardy:

OpenSSL is there because people decided to fork and maintain it.

It would be valuable to get some information about people behind openssl.

Here a list of people i (see history of this page to know who i ami since i am not in this list) believe would have an history for current history (2014 2015) of OpenSSL.

( I created this page with a hidden agenda to prepare for 28th November a presentation in french in a Linux local event, but this might have a higher value ).

<pre>
- Initial creator
Eric Andrew Young and Tim Hudson

- OpenSSL foundation ( and not already cited )
Dr. Steve Henson
Richard Levitte
Steve Marquess
Rich Salz

Official developers ( and not already cited )
Matt Caswell
Mark J. Cox
Viktor Dukhovni
Lutz Jänicke
Emilia Käsper
Ben Laurie
Steve Marquess
Richard Levitte
Bodo Möller
Andy Polyakov
Kurt Roeckx
Geoff Thorpe

And valuable 2015 contributors :

Jonas Maebe
Felix Laurie von Massenbach
</pre>

Don't feel offended if you are not cited here, if you consider to have something usefull to add you anyway will have more inner view than i am.

Here a possible set of question :

- Why did you come to this project ?
- What is your focus area on this project ?
- How did you feel about heartbleed ?
- Why do you stay ?
- What is your dream for OpenSSL future ?
- Are there things you would do differently now than before – a specific CVE event affected a piece of code you were directly or indirectly involved - . ?
- Anything else that you find relevant.

History And People

2015-10-14T18:48:11Z

Philippe lhardy:

OpenSSL is there because people decided to fork and maintain it.

I would be valuable to get some information about people behind openssl.

Here a list of people i (see history of this page to know who i ami since i am not in this list) believe would have an history for current history (2014 2015) of OpenSSL.

( I created this page with a hidden agenda to prepare for 28th November a presentation in french in a Linux local event, but this might have a higher value ).

<pre>
- Initial creator
Eric Andrew Young and Tim Hudson

- OpenSSL foundation ( and not already cited )
Dr. Steve Henson
Richard Levitte
Steve Marquess
Rich Salz

Official developers ( and not already cited )
Matt Caswell
Mark J. Cox
Viktor Dukhovni
Lutz Jänicke
Emilia Käsper
Ben Laurie
Steve Marquess
Richard Levitte
Bodo Möller
Andy Polyakov
Kurt Roeckx
Geoff Thorpe

And valuable 2015 contributors :

Jonas Maebe
Felix Laurie von Massenbach
</pre>

Don't feel offended if you are not cited here, if you consider to have something usefull to add you anyway will have more inner view than i am.

Here a possible set of question :

- Why did you come to this project ?
- What is your focus area on this project ?
- How did you feel about heartbleed ?
- Why do you stay ?
- What is your dream for OpenSSL future ?
- Are there things you would do differently now than before – a specific CVE event affected a piece of code you were directly or indirectly involved - . ?
- Anything else that you find relevant.

History And People

2015-10-14T18:47:30Z

Philippe lhardy:

OpenSSL is there because people decided to fork and maintain it.

I would be valuable to get some information about people behind openssl.

Here a list of people i (see history of this page to know who i ami since i am not in this list) believe would have an history for current history of OpenSSL.

( I created this page with a hidden agenda to prepare for 28th November a presentation in french in a Linux local event, but this might have a higher value ).

<pre>
- Initial creator
Eric Andrew Young and Tim Hudson

- OpenSSL foundation ( and not already cited )
Dr. Steve Henson
Richard Levitte
Steve Marquess
Rich Salz

Official developers ( and not already cited )
Matt Caswell
Mark J. Cox
Viktor Dukhovni
Lutz Jänicke
Emilia Käsper
Ben Laurie
Steve Marquess
Richard Levitte
Bodo Möller
Andy Polyakov
Kurt Roeckx
Geoff Thorpe

And valuable 2015 contributors :

Jonas Maebe
Felix Laurie von Massenbach
</pre>

Don't feel offended if you are not cited here, if you consider to have something usefull to add you anyway will have more inner view than i am.

Here a possible set of question :

- Why did you come to this project ?
- What is your focus area on this project ?
- How did you feel about heartbleed ?
- Why do you stay ?
- What is your dream for OpenSSL future ?
- Are there things you would do differently now than before – a specific CVE event affected a piece of code you were directly or indirectly involved - . ?
- Anything else that you find relevant.

History And People

2015-10-14T18:47:05Z

Philippe lhardy: Who are OpenSSL humans ?

OpenSSL is there because people decided to fork and maintain it.

I would be valuable to get some information about people behind openssl.

Here a list of people i (see history of this page to know who i ami since i am not in this list) believe would have an history for current history of OpenSSL.

( I created this page with a hidden agenda to prepare for 28th November a presentation in french in a Linux local event, but this might have a higher value ).

- Initial creator
Eric Andrew Young and Tim Hudson

- OpenSSL foundation ( and not already cited )
Dr. Steve Henson
Richard Levitte
Steve Marquess
Rich Salz

Official developers ( and not already cited )
Matt Caswell
Mark J. Cox
Viktor Dukhovni
Lutz Jänicke
Emilia Käsper
Ben Laurie
Steve Marquess
Richard Levitte
Bodo Möller
Andy Polyakov
Kurt Roeckx
Geoff Thorpe

And valuable 2015 contributors :

Jonas Maebe
Felix Laurie von Massenbach

Don't feel offended if you are not cited here, if you consider to have something usefull to add you anyway will have more inner view than i am.

Here a possible set of question :

- Why did you come to this project ?
- What is your focus area on this project ?
- How did you feel about heartbleed ?
- Why do you stay ?
- What is your dream for OpenSSL future ?
- Are there things you would do differently now than before – a specific CVE event affected a piece of code you were directly or indirectly involved - . ?
- Anything else that you find relevant.

OpenSSL Overview

2015-10-14T18:38:05Z

Philippe lhardy: /* Command Line */

OpenSSL is a versatile tool that can be used for many purposes.

OpenSSL provides:

* A command line application to perform a wide variety of cryptography tasks, such as creating and handling certificates and related files. [[Command_Line_Utilities|OpenSSL commands]]
* A comprehensive and extensive cryptographic library [[Libcrypto_API|libcrypto]].
* A library for enabling SSL/TLS communications [[Libssl_API|libssl]] to provide [[SSL and TLS Protocols]] support within clients or servers applications.

== Command Line ==

Example uses of the OpenSSL command line tool include:
* Creating and handling certificates and related files. [[Command_Line_Utilities|openssl commands]]. A beginners introduction to certificates is on the [[Certificate Lifecycle]] page.
* Testing of SSL/TLS protocols (openssl s_server, openssl s_client).

== History ==

[[History And People]]

[[Category:Beginner]]

Compilation and Installation

2015-03-22T19:27:43Z

Philippe lhardy: /* Retrieve source code */

== Retrieve source code ==

The OpenSSL source code can be downloaded from [http://www.openssl.org/source/ www.openssl.org/source/] or any suitable [http://www.openssl.org/source/mirror.html ftp mirror]. There are various versions including stable as well as unstable versions.

The source code is managed via Git, the repository is

: git://git.openssl.org/openssl.git

The source is also available via a [https://github.com/openssl/openssl GitHub] mirror. This repository is updated every 15 minutes.

* [[Use_of_Git|Accessing OpenSSL source code via Git]]

== Configuration ==

OpenSSL is configured for a particular platform with protocol and behavior options using <tt>Configure</tt> and <tt>config</tt>.

=== Configure & Config ===

You use <tt>Configure</tt> and <tt>config</tt> to tune the compile and installation process through options and switches. The difference between is <tt>Configure</tt> properly handles the host-arch-compiler triplet, and <tt>config</tt> does not. <tt>config</tt> attempts to guess the triplet, so its a lot like autotool's <tt>config.guess</tt>.

You can usually use <tt>config</tt> and it will do the right thing (from Ubuntu 13.04, x64):

<pre>$ ./config
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
Configuring for linux-x86_64
no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-md2 [default] OPENSSL_NO_MD2 (skip dir)
no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default] OPENSSL_NO_SCTP (skip dir)
no-shared [default]
no-store [experimental] OPENSSL_NO_STORE (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
...</pre>

Mac OSX is a problem (its often a neglected platform), and you will have to use <tt>Configure</tt>:

<pre> ./Configure darwin64-x86_64-cc
Configuring for darwin64-x86_64-cc
no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-md2 [default] OPENSSL_NO_MD2 (skip dir)
no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default] OPENSSL_NO_SCTP (skip dir)
no-shared [default]
no-store [experimental] OPENSSL_NO_STORE (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
...</pre>

Running the same command with <tt>config</tt> results in:

<pre>$ ./config darwin64-x86_64-cc
Operating system: i686-apple-darwinDarwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64
WARNING! If you wish to build 64-bit library, then you have to
invoke './Configure darwin64-x86_64-cc' *manually*.
You have about 5 seconds to press Ctrl-C to abort.
Configuring for darwin-i386-cc
target already defined - darwin-i386-cc (offending arg: darwin64-x86_64-cc)</pre>

You can also configure on Darwin by exporting <tt>KERNEL_BITS</tt>:

<pre>$ export KERNEL_BITS=64
$ ./config shared no-ssl2 enable-ec_nistp_64_gcc_128 --openssldir=/usr/local/ssl/macosx-x64/
Operating system: i686-apple-darwinDarwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64
Configuring for darwin64-x86_64-cc
Configuring for darwin64-x86_64-cc
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-md2 [default] OPENSSL_NO_MD2 (skip dir)
no-psk [option] OPENSSL_NO_PSK (skip dir)
no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default] OPENSSL_NO_SCTP (skip dir)
no-srp [option] OPENSSL_NO_SRP (skip dir)
no-ssl2 [option] OPENSSL_NO_SSL2 (skip dir)
no-store [experimental] OPENSSL_NO_STORE (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
...</pre>

If you provide a option not known to configure or ask for help, then you get a brief help message:

<pre>$ ./Configure --help
Usage: Configure [no-<cipher> ...] [enable-<cipher> ...] [experimental-<cipher> ...]
[-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared]
[[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-krb5] [sctp] [386] [--prefix=DIR]
[--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags]</pre>

And if you supply an unknown triplet:

<pre>$ ./Configure darwin64-x86_64-clang
Configuring for darwin64-x86_64-clang
Usage: Configure [no-<cipher> ...] [enable-<cipher> ...] [experimental-<cipher> ...]
[-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared]
[[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-krb5] [sctp] [386] [--prefix=DIR]
[--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags]

pick os/compiler from:
BC-32 BS2000-OSD BSD-generic32 BSD-generic64 BSD-ia64 BSD-sparc64 BSD-sparcv8
BSD-x86 BSD-x86-elf BSD-x86_64 Cygwin Cygwin-pre1.3 DJGPP MPE/iX-gcc OS2-EMX
OS390-Unix QNX6 QNX6-i386 ReliantUNIX SINIX SINIX-N UWIN VC-CE VC-WIN32
VC-WIN64A VC-WIN64I aix-cc aix-gcc aix3-cc aix64-cc aix64-gcc android
android-armv7 android-x86 aux3-gcc beos-x86-bone beos-x86-r5 bsdi-elf-gcc cc
cray-j90 cray-t3e darwin-i386-cc darwin-ppc-cc darwin64-ppc-cc
darwin64-x86_64-cc dgux-R3-gcc dgux-R4-gcc dgux-R4-x86-gcc dist gcc hpux-cc
hpux-gcc hpux-ia64-cc hpux-ia64-gcc hpux-parisc-cc hpux-parisc-cc-o4
hpux-parisc-gcc hpux-parisc1_1-cc hpux-parisc1_1-gcc hpux-parisc2-cc
hpux-parisc2-gcc hpux64-ia64-cc hpux64-ia64-gcc hpux64-parisc2-cc
hpux64-parisc2-gcc hurd-x86 iphoneos-cross irix-cc irix-gcc irix-mips3-cc
irix-mips3-gcc irix64-mips4-cc irix64-mips4-gcc linux-alpha+bwx-ccc
linux-alpha+bwx-gcc linux-alpha-ccc linux-alpha-gcc linux-aout linux-armv4
linux-elf linux-generic32 linux-generic64 linux-ia32-icc linux-ia64
linux-ia64-ecc linux-ia64-icc linux-ppc linux-ppc64 linux-sparcv8
linux-sparcv9 linux-x86_64 linux32-s390x linux64-s390x linux64-sparcv9 mingw
mingw64 ncr-scde netware-clib netware-clib-bsdsock netware-clib-bsdsock-gcc
...

NOTE: If in doubt, on Unix-ish systems use './config'.</pre>

Finally, to delete a configuration and start anew, run <tt>make dclean</tt>.

=== Configure Options ===

OpenSSL has been around a long time, and it carries around a lot of cruft. For example, from above, SSLv2 is enabled by default. SSLv2 is completely broken, and you should disable it during configuration. You can disable protocols and provide other options through <tt>Configure</tt> and <tt>config</tt>, and the following lists some of them.

'''Note''': if you specify a non-existent option, then the configure scripts will proceed without warning. For example, if you inadvertently specify '''no-sslv2''' rather than '''no-ssl2''', the script will configure ''with'' SSLv2 and ''without'' warning for the unknown no-sslv2.

{| class="wikitable sortable" border="1"
|+ OpenSSL Library Options
|-
! scope="col" width="150px" | Option
! scope="col" class="unsortable" | Description
|-
| --openssldir=XXX || The installation directory. If not specified, the library will be installed at <tt>/usr/local/ssl</tt>. Header will be located at <tt>/usr/local/ssl/include/openssl</tt>, and libraries located at <tt>/usr/local/ssl/lib</tt>.
|-
| shared || Build a shared object in addition to the static archive
|-
| enable-ec_nistp_64_gcc_128 || Use on x64 platforms when GCC supports <tt>__uint128_t</tt>. ECDH is about 2 to 4 times faster. Not enabled by default because <tt>Configure</tt> can't determine it.
|-
| no-ssl2 || Disables SSLv2. <tt>OPENSSL_NO_SSL2</tt> will be defined in the OpenSSL headers.
|-
| no-ssl3 || Disables SSLv3. <tt>OPENSSL_NO_SSL3</tt> will be defined in the OpenSSL headers.
|-
| no-comp || Disables compression independent of <tt>zlib</tt>. <tt>OPENSSL_NO_COMP</tt> will be defined in the OpenSSL headers.
|-
| no-idea || Disables IDEA algorithm. Unlike RC5 and MDC2, IDEA is enabled by default
|-
| no-asm || Disables assembly language routines (and uses C routines)
|-
| no-dtls || Disables DTLS (useful on mobile devices since carriers often block UDP)
|-
| no-shared || Disables shared objects (only a static library is created)
|-
| no-hw || Disables hardware support (useful on mobile devices)
|-
| no-engines || Disables hardware support (useful on mobile devices)
|-
| no-threads || Disables threading support
|-
| no-dso || Disables the OpenSSL DSO API (the library offers a shared object abstraction layer)
|-
| no-err || Removes all error function names and error reason text to reduce footprint
|-
| no-npn || Disables Next Protocol Negotiation (NPN)
|-
| no-psk || Disables Preshared Key (PSK). PSK provides mutual authentication independent of trusted authorities, but its rarely offered or used
|-
| no-srp || Disables Secure Remote Password (SRP). SRP provides mutual authentication independent of trusted authorities, but its rarely offered or used
|-
| no-ec2m || Used when configuring FIPS Capable Library with a FIPS Object Module that only includes prime curves. That is, use this switch if you use <tt>openssl-fips-ecp-2.0.5</tt>.
|-
| -DXXX || Defines XXX. For example, <tt>-DOPENSSL_NO_HEARTBEATS</tt>.
|-
| -DOPENSSL_USE_IPV6=0 || Disables IPv6. Useful if OpenSSL encounters incorrect or inconsistent platform headers and mistakenly enables IPv6. Must be passed to <tt>Configure</tt> manually.
|}

After disabling an option, your configure output will look similar to below (notice the lack of SSLv2 and SSLv3 support).

<pre>$ ./Configure darwin64-x86_64-cc no-ssl2 no-ssl3
Configuring for darwin64-x86_64-cc
no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
no-gmp [default] OPENSSL_NO_GMP (skip dir)
no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir)
no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5
no-md2 [default] OPENSSL_NO_MD2 (skip dir)
no-rc5 [default] OPENSSL_NO_RC5 (skip dir)
no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir)
no-sctp [default] OPENSSL_NO_SCTP (skip dir)
no-shared [default]
no-ssl2 [option] OPENSSL_NO_SSL2 (skip dir)
no-ssl3 [option] OPENSSL_NO_SSL3 (skip dir)
no-store [experimental] OPENSSL_NO_STORE (skip dir)
no-zlib [default]
no-zlib-dynamic [default]
...</pre>

=== Compile Time Checking ===

If you disable an option during configure, you can check if it's available through <tt>OPENSSL_NO_*</tt> defines. OpenSSL writes the configure options to <tt><openssl/opensslconf.h></tt>. For example, if you want to know if SSLv3 is available, then you would perform the following in your code:

<pre>#include <openssl/opensslconf.h>
...

#if !defined(OPENSSL_NO_SSL3)
/* SSLv3 is available */
#endif</pre>

=== Modifying Build Settings ===

Sometimes you need to work around OpenSSL's selections for building the library. For example, you might want to use <tt>-Os</tt> for a mobile device (rather than <tt>-O3</tt>), or you might want to use the <tt>clang</tt> compiler (rather than <tt>gcc</tt>).

In case like these, its often easier to modify <tt>Configure</tt> and <tt>Makefile.org</tt> rather than trying to add targets to the configure scripts. Below is a patch that modifies <tt>Configure</tt> and <tt>Makefile.org</tt> for use under the iOS 7.0 SDK (which lacks <tt>gcc</tt> in <tt>/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/</tt>):

* Modifies <tt>Configure</tt> to use <tt>clang</tt>
* Modifies <tt>Makefile.org</tt> to use <tt>clang</tt>
* Modifies <tt>CFLAG</tt> to use <tt>-Os</tt>
* Modifies <tt>MAKEDEPPROG</tt> to use <tt>$(CC) -M</tt>

Setting and resetting of <tt>LANG</tt> is required on Mac OSX to work around a <tt>sed</tt> bug or limitation.

<pre>OLD_LANG=$LANG
unset LANG

sed -i "" 's|\"iphoneos-cross\"\,\"llvm-gcc\:-O3|\"iphoneos-cross\"\,\"clang\:-Os|g' Configure
sed -i "" 's/CC= cc/CC= clang/g' Makefile.org
sed -i "" 's/CFLAG= -O/CFLAG= -Os/g' Makefile.org
sed -i "" 's/MAKEDEPPROG=makedepend/MAKEDEPPROG=$(CC) -M/g' Makefile.org

export LANG=$OLD_LANG</pre>

After modification, be sure to dclean and configure again so the new settings are picked up:

<pre>make dclean

./config
make depend
make all
...</pre>

=== Fedora and Red Hat ===

On Fedora and Red Hat systems, be sure to export <tt>CFLAGS="-fPIC"</tt> and explicitly specify <tt>shared</tt> to <tt>config</tt>. Failing to do so will result in static libraries only.That is, you will be missing the shared objects and engines. The commands would look similar to below.

<pre>$ export CFLAGS="-fPIC"
$ ./config shared no-ssl2 no-ssl3 --openssldir=/usr/local/ssl
...
$ make depend
...
$ make all
...
$ sudo -E make install</pre>

=== FIPS Capable Library ===

If you want to use FIPS validated cryptography, you download, build and install the FIPS Object Module (<tt>openssl-fips-2.0.5.tar.gz</tt>) according to the [https://www.openssl.org/docs/fips/UserGuide-2.0.pdf FIPS User Guide 2.0] and [https://www.openssl.org/docs/fips/SecurityPolicy-2.0.pdf FIPS 140-2 Security Policy]. You then download, build and install the FIPS Capable Library (<tt>openssl-1.0.1e.tar.gz</tt>).

When configuring the FIPS Capable Library, you must use <tt>fips</tt> as an option:

<pre>./config fips <other options ...></pre>

If you are configuring the FIPS Capable Library with only prime curves (<tt>openssl-fips-ecp-2.0.5.tar.gz</tt>), then you must configure with <tt>no-ec2m</tt>:

<pre>./config fips no-ec2m <other options ...></pre>

== Compilation ==

Once you untar the source files (or fetched them from source control), its a good idea to look at README provided in it.

<pre>cat README</pre>

where you will understand that you have to read another file INSTALL :

<pre>cat INSTALL</pre>

Depending on your platform you will have to pick up the right INSTALL by example INSTALL.W64.
Default is for Unix based systems.

==== Quick ====

<pre>./config <nowiki><options ...></nowiki>
make depend
make
make test
make install</pre>

Various options can be found examining the <tt>Configure</tt> file (there is a well commented block at its top). OpenSSL ships with SSLv2, SSLv3 and Compression enabled by default (see <tt>my $disabled</tt>), so you might want to use <tt>no-ssl2</tt>, <tt>no-ssl3</tt>, and <tt>no-comp</tt>.

== Platfom specific ==

=== Linux ===

==== Intel ====

==== ARM ====

=== Windows ===
3noch wrote a VERY good guide [http://developer.covenanteyes.com/building-openssl-for-visual-studio/ here].
Like he said in his article, make absolutely sure to create separate directories for 32 and 64 bit versions.

==== W32 / Windows NT - Windows 9x ====

type INSTALL.W32

* you need Perl for Win32. Unless you will build on Cygwin, you will need ActiveState Perl, available from http://www.activestate.com/ActivePerl.
* one of the following C compilers:
** Visual C++
** Borland C
** GNU C (Cygwin or MinGW)
* Netwide Assembler, a.k.a. NASM, available from http://nasm.sourceforge.net/ is required if you intend to utilize assembler modules. Note that NASM is now the only supported assembler.

==== W64 ====

Read first the INSTALL.W64 documentation note containing some specific 64bits information.
See also INSTALL.W32 that still provides additonnal build information common to both the 64 and 32 bit versions.

You may be surprised: the 64bit artefacts are indeed output in the out32* sub-directories and bear names ending *32.dll. Fact is the 64 bit compile target is so far an incremental change over the legacy 32bit windows target. Numerous compile flags are still labelled "32" although those do apply to both 32 and 64bit targets.

The important pre-requisites are to have PERL available (for essential file processing so as to prepare sources and scripts for the target OS) and of course a C compiler like Microsoft Visual Studio for C/C++.

Using MS Visual Studio:
# launch a Visual Studio tool x64 Cross Tools Command prompt
# change to the directory where you have copied openssl sources <code>cd c:\myPath\openssl</code>
# configure for the target OS with the command <code>perl Configure VC-WIN64A</code>. You may also be interested to set more configuration options as documented in the general INSTALL note (for UNIX targets). For instance: <code>perl Configure no-asm VC-WIN64A</code>.
# prepare the target environment with the command: <code>ms\do_win64a</code>
# ensure you start afresh and notably without linkable products from a previous 32bit compile (as 32 and 64 bits compiling still share common directories) with the command: <code>nmake -f ms\ntdll.mak clean</code> for the DLL target and <code>nmake -f ms\nt.mak clean</code> for static libraries.
# build the code with: <code>nmake -f ms\ntdll.mak</code> (respectively <code>nmake -f ms\nt.mak</code> )
# the artefacts will be found in sub directories out32dll and out32dll.dbg (respectively out32 and out32.dbg for static libraries). The libcrypto and ssl libraries are still named libeay32.lib and ssleay32.lib, and associated includes in inc32 ! You may check this is true 64bit code using the Visual Studio tool 'dumbin'. For instance <code>dumpbin /headers out32dll/libeay32.lib | more</code>, and look at the FILE HEADER section.
# test the code using the various *test.exe programs in out32dll. Use the 'test' make target to run all tests as in <code>nmake -f ms\ntdll.mak test</code>
# we recommend that you move/copy needed includes and libraries from the "32" directories under a new explicit directory tree for 64bit applications from where you will import and link your target applications, similar to that explained in INSTALL.W32.

==== Windows CE ====

=== Mac ===

The earlier discussion presented a lot of information (and some of it had OS X information). Here are the TLDR versions to configure, build and install the library.

If configuring for 64-bit OS X, then use a command similar to:

<pre>./Configure darwin64-x86_64-cc enable-ec_nistp_64_gcc_128 no-ssl2 no-ssl3 no-comp --openssldir=/usr/local/ssl/macos-x86_64
make
sudo make install</pre>

If configuring for 32-bit OS X, then use a command similar to:

<pre>./Configure darwin64-i386-cc no-ssl2 no-ssl3 no-comp --openssldir=/usr/local/ssl/macosx-i386
make
sudo make install</pre>

=== iOS ===

=== Android ===

Visit [[Android]] and [[FIPS Library and Android]].

=== More ===

==== VAX/VMS ====

I you wonder what are files ending with .com like test/testca.com those are VAX/VMX scripts.
This code is still maintained.

==== OS/2 ====

==== NetWare ====
5.x 6.x

==== HP-UX ====
[[HP-UX Itanium FIPS and OpenSSL build]]

[[Category:Shell level]]
[[Category:Installation]]
[[Category:Compilation]]

Hostname validation

2015-01-26T19:19:44Z

Philippe lhardy: /* Recommendation */ add code sample

One [https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html very common mistake] made by users of OpenSSL is to assume that OpenSSL will validate the hostname in the server's certificate. Currently, it does not, although a future version (1.1.0?) will include this functionality.

== Recommendation ==

(extracted from mailling list discussion answer from Viktor Dukhovni who actual did implement part of host checking extensions )

Starting with 1.0.2 version use '''X509_check_host()''' https://www.openssl.org/docs/crypto/X509_check_host.html interface

sample :

<pre>
const char *servername;
SSL *ssl;
X509_VERIFY_PARAM *param;

servername = "www.example.com";
ssl = SSL_new(...);
param = SSL_get0_param(ssl);

/* Enable automatic hostname checks */
X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
X509_VERIFY_PARAM_set1_host(param, servername, 0);

/* Configure a non-zero callback if desired */
SSL_set_verify(ssl, SSL_VERIFY_PEER, 0);

/*
* Establish SSL connection, hostname should be checked
* automatically test with a hostname that should not match,
* the connection will fail (unless you specify a callback
* that returns despite the verification failure. In that
* case SSL_get_verify_status() can expose the problem after
* connection completion.
*/
...
</pre>

Wildcard support is configured via the flags documented for X509_check_host(), the two most frequently useful are:
* '''X509_CHECK_FLAG_NO_WILDCARDS'''
* '''X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS'''

populate the X509_VERIFY_PARAMS with the desired hostname, and let the OpenSSL code call X509_check_host automatically.

This makes it easier to some day enable DANE TLSA support, because with DANE, name checks need to be skipped for DANE-EE(3) TLSA records, as the DNSSEC TLSA records provides the requisite name
binding instead.

Also with the X509_VERIFY_PARAM approach, name checks happen early, and for applications that don't continue handshakes with unauthenticated peers, terminate as early as possible.

There is an associated new X509 error code: '''X509_V_ERR_HOSTNAME_MISMATCH'''

== cUrl code ==

This was the original information, might still be valid for < 1.0.2 openssl versions :

[https://github.com/iSECPartners/ssl-conservatory Here is some sample code] which shows how validating the hostname can be done. However, it does not handle wildcard certificates, so [http://archives.seul.org/libevent/users/Feb-2013/msg00043.html borrowing some code from cURL] might be one way to go.

for sake of simplicity i copied here the related code of last CURL reference :

<pre>
/* Obtained from: https://github.com/iSECPartners/ssl-conservatory */

/*
Copyright (C) 2012, iSEC Partners.

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
*/

/*
* Helper functions to perform basic hostname validation using OpenSSL.
*
* Please read "everything-you-wanted-to-know-about-openssl.pdf" before
* attempting to use this code. This whitepaper describes how the code works,
* how it should be used, and what its limitations are.
*
* Author: Alban Diquet
* License: See LICENSE
*
*/

// Get rid of OSX 10.7 and greater deprecation warnings.
#if defined(__APPLE__) && defined(__clang__)
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
#endif

#include <openssl/x509v3.h>
#include <openssl/ssl.h>

#include "openssl_hostname_validation.h"
#include "hostcheck.h"

#define HOSTNAME_MAX_SIZE 255

/**
* Tries to find a match for hostname in the certificate's Common Name field.
*
* Returns MatchFound if a match was found.
* Returns MatchNotFound if no matches were found.
* Returns MalformedCertificate if the Common Name had a NUL character embedded in it.
* Returns Error if the Common Name could not be extracted.
*/
static HostnameValidationResult matches_common_name(const char *hostname, const X509 *server_cert) {
int common_name_loc = -1;
X509_NAME_ENTRY *common_name_entry = NULL;
ASN1_STRING *common_name_asn1 = NULL;
char *common_name_str = NULL;

// Find the position of the CN field in the Subject field of the certificate
common_name_loc = X509_NAME_get_index_by_NID(X509_get_subject_name((X509 *) server_cert), NID_commonName, -1);
if (common_name_loc < 0) {
return Error;
}

// Extract the CN field
common_name_entry = X509_NAME_get_entry(X509_get_subject_name((X509 *) server_cert), common_name_loc);
if (common_name_entry == NULL) {
return Error;
}

// Convert the CN field to a C string
common_name_asn1 = X509_NAME_ENTRY_get_data(common_name_entry);
if (common_name_asn1 == NULL) {
return Error;
}
common_name_str = (char *) ASN1_STRING_data(common_name_asn1);

// Make sure there isn't an embedded NUL character in the CN
if ((size_t)ASN1_STRING_length(common_name_asn1) != strlen(common_name_str)) {
return MalformedCertificate;
}

// Compare expected hostname with the CN
if (Curl_cert_hostcheck(common_name_str, hostname) == CURL_HOST_MATCH) {
return MatchFound;
}
else {
return MatchNotFound;
}
}

/**
* Tries to find a match for hostname in the certificate's Subject Alternative Name extension.
*
* Returns MatchFound if a match was found.
* Returns MatchNotFound if no matches were found.
* Returns MalformedCertificate if any of the hostnames had a NUL character embedded in it.
* Returns NoSANPresent if the SAN extension was not present in the certificate.
*/
static HostnameValidationResult matches_subject_alternative_name(const char *hostname, const X509 *server_cert) {
HostnameValidationResult result = MatchNotFound;
int i;
int san_names_nb = -1;
STACK_OF(GENERAL_NAME) *san_names = NULL;

// Try to extract the names within the SAN extension from the certificate
san_names = X509_get_ext_d2i((X509 *) server_cert, NID_subject_alt_name, NULL, NULL);
if (san_names == NULL) {
return NoSANPresent;
}
san_names_nb = sk_GENERAL_NAME_num(san_names);

// Check each name within the extension
for (i=0; i<san_names_nb; i++) {
const GENERAL_NAME *current_name = sk_GENERAL_NAME_value(san_names, i);

if (current_name->type == GEN_DNS) {
// Current name is a DNS name, let's check it
char *dns_name = (char *) ASN1_STRING_data(current_name->d.dNSName);

// Make sure there isn't an embedded NUL character in the DNS name
if ((size_t)ASN1_STRING_length(current_name->d.dNSName) != strlen(dns_name)) {
result = MalformedCertificate;
break;
}
else { // Compare expected hostname with the DNS name
if (Curl_cert_hostcheck(dns_name, hostname)
== CURL_HOST_MATCH) {
result = MatchFound;
break;
}
}
}
}
sk_GENERAL_NAME_pop_free(san_names, GENERAL_NAME_free);

return result;
}

/**
* Validates the server's identity by looking for the expected hostname in the
* server's certificate. As described in RFC 6125, it first tries to find a match
* in the Subject Alternative Name extension. If the extension is not present in
* the certificate, it checks the Common Name instead.
*
* Returns MatchFound if a match was found.
* Returns MatchNotFound if no matches were found.
* Returns MalformedCertificate if any of the hostnames had a NUL character embedded in it.
* Returns Error if there was an error.
*/
HostnameValidationResult validate_hostname(const char *hostname, const X509 *server_cert) {
HostnameValidationResult result;

if((hostname == NULL) || (server_cert == NULL))
return Error;

// First try the Subject Alternative Names extension
result = matches_subject_alternative_name(hostname, server_cert);
if (result == NoSANPresent) {
// Extension was not found: try the Common Name
result = matches_common_name(hostname, server_cert);
}

return result;
}

</pre>

[[Category:SSL/TLS]]
[[Category:Common Mistake]]
[[Category:Examples]]

Hostname validation

2015-01-26T17:55:25Z

Philippe lhardy: /* cUrl code */

One [https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html very common mistake] made by users of OpenSSL is to assume that OpenSSL will validate the hostname in the server's certificate. Currently, it does not, although a future version (1.1.0?) will include this functionality.

== Recommendation ==

(extracted from mailling list discussion answer from Viktor Dukhovni)

Starting with 1.0.2 version use '''X509_check_host()''' https://www.openssl.org/docs/crypto/X509_check_host.html interface

Wildcard support is configured via the flags documented for X509_check_host(), the two most frequently useful are:
* '''X509_CHECK_FLAG_NO_WILDCARDS'''
* '''X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS'''

populate the X509_VERIFY_PARAMS with the desired hostname, and let the OpenSSL code call X509_check_host automatically.

This makes it easier to some day enable DANE TLSA support, because with DANE, name checks need to be skipped for DANE-EE(3) TLSA records, as the DNSSEC TLSA records provides the requisite name
binding instead.

Also with the X509_VERIFY_PARAM approach, name checks happen early, and for applications that don't continue handshakes with unauthenticated peers, terminate as early as possible.

There is an associated new X509 error code: '''X509_V_ERR_HOSTNAME_MISMATCH'''

== cUrl code ==

This was the original information, might still be valid for < 1.0.2 openssl versions :

[https://github.com/iSECPartners/ssl-conservatory Here is some sample code] which shows how validating the hostname can be done. However, it does not handle wildcard certificates, so [http://archives.seul.org/libevent/users/Feb-2013/msg00043.html borrowing some code from cURL] might be one way to go.

for sake of simplicity i copied here the related code of last CURL reference :

<pre>
/* Obtained from: https://github.com/iSECPartners/ssl-conservatory */

/*
Copyright (C) 2012, iSEC Partners.

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
*/

/*
* Helper functions to perform basic hostname validation using OpenSSL.
*
* Please read "everything-you-wanted-to-know-about-openssl.pdf" before
* attempting to use this code. This whitepaper describes how the code works,
* how it should be used, and what its limitations are.
*
* Author: Alban Diquet
* License: See LICENSE
*
*/

// Get rid of OSX 10.7 and greater deprecation warnings.
#if defined(__APPLE__) && defined(__clang__)
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
#endif

#include <openssl/x509v3.h>
#include <openssl/ssl.h>

#include "openssl_hostname_validation.h"
#include "hostcheck.h"

#define HOSTNAME_MAX_SIZE 255

/**
* Tries to find a match for hostname in the certificate's Common Name field.
*
* Returns MatchFound if a match was found.
* Returns MatchNotFound if no matches were found.
* Returns MalformedCertificate if the Common Name had a NUL character embedded in it.
* Returns Error if the Common Name could not be extracted.
*/
static HostnameValidationResult matches_common_name(const char *hostname, const X509 *server_cert) {
int common_name_loc = -1;
X509_NAME_ENTRY *common_name_entry = NULL;
ASN1_STRING *common_name_asn1 = NULL;
char *common_name_str = NULL;

// Find the position of the CN field in the Subject field of the certificate
common_name_loc = X509_NAME_get_index_by_NID(X509_get_subject_name((X509 *) server_cert), NID_commonName, -1);
if (common_name_loc < 0) {
return Error;
}

// Extract the CN field
common_name_entry = X509_NAME_get_entry(X509_get_subject_name((X509 *) server_cert), common_name_loc);
if (common_name_entry == NULL) {
return Error;
}

// Convert the CN field to a C string
common_name_asn1 = X509_NAME_ENTRY_get_data(common_name_entry);
if (common_name_asn1 == NULL) {
return Error;
}
common_name_str = (char *) ASN1_STRING_data(common_name_asn1);

// Make sure there isn't an embedded NUL character in the CN
if ((size_t)ASN1_STRING_length(common_name_asn1) != strlen(common_name_str)) {
return MalformedCertificate;
}

// Compare expected hostname with the CN
if (Curl_cert_hostcheck(common_name_str, hostname) == CURL_HOST_MATCH) {
return MatchFound;
}
else {
return MatchNotFound;
}
}

/**
* Tries to find a match for hostname in the certificate's Subject Alternative Name extension.
*
* Returns MatchFound if a match was found.
* Returns MatchNotFound if no matches were found.
* Returns MalformedCertificate if any of the hostnames had a NUL character embedded in it.
* Returns NoSANPresent if the SAN extension was not present in the certificate.
*/
static HostnameValidationResult matches_subject_alternative_name(const char *hostname, const X509 *server_cert) {
HostnameValidationResult result = MatchNotFound;
int i;
int san_names_nb = -1;
STACK_OF(GENERAL_NAME) *san_names = NULL;

// Try to extract the names within the SAN extension from the certificate
san_names = X509_get_ext_d2i((X509 *) server_cert, NID_subject_alt_name, NULL, NULL);
if (san_names == NULL) {
return NoSANPresent;
}
san_names_nb = sk_GENERAL_NAME_num(san_names);

// Check each name within the extension
for (i=0; i<san_names_nb; i++) {
const GENERAL_NAME *current_name = sk_GENERAL_NAME_value(san_names, i);

if (current_name->type == GEN_DNS) {
// Current name is a DNS name, let's check it
char *dns_name = (char *) ASN1_STRING_data(current_name->d.dNSName);

// Make sure there isn't an embedded NUL character in the DNS name
if ((size_t)ASN1_STRING_length(current_name->d.dNSName) != strlen(dns_name)) {
result = MalformedCertificate;
break;
}
else { // Compare expected hostname with the DNS name
if (Curl_cert_hostcheck(dns_name, hostname)
== CURL_HOST_MATCH) {
result = MatchFound;
break;
}
}
}
}
sk_GENERAL_NAME_pop_free(san_names, GENERAL_NAME_free);

return result;
}

/**
* Validates the server's identity by looking for the expected hostname in the
* server's certificate. As described in RFC 6125, it first tries to find a match
* in the Subject Alternative Name extension. If the extension is not present in
* the certificate, it checks the Common Name instead.
*
* Returns MatchFound if a match was found.
* Returns MatchNotFound if no matches were found.
* Returns MalformedCertificate if any of the hostnames had a NUL character embedded in it.
* Returns Error if there was an error.
*/
HostnameValidationResult validate_hostname(const char *hostname, const X509 *server_cert) {
HostnameValidationResult result;

if((hostname == NULL) || (server_cert == NULL))
return Error;

// First try the Subject Alternative Names extension
result = matches_subject_alternative_name(hostname, server_cert);
if (result == NoSANPresent) {
// Extension was not found: try the Common Name
result = matches_common_name(hostname, server_cert);
}

return result;
}

</pre>

[[Category:SSL/TLS]]
[[Category:Common Mistake]]
[[Category:Examples]]

Hostname validation

2015-01-26T17:54:26Z

Philippe lhardy: /* Recommendation */

One [https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html very common mistake] made by users of OpenSSL is to assume that OpenSSL will validate the hostname in the server's certificate. Currently, it does not, although a future version (1.1.0?) will include this functionality.

== Recommendation ==

(extracted from mailling list discussion answer from Viktor Dukhovni)

Starting with 1.0.2 version use '''X509_check_host()''' https://www.openssl.org/docs/crypto/X509_check_host.html interface

Wildcard support is configured via the flags documented for X509_check_host(), the two most frequently useful are:
* '''X509_CHECK_FLAG_NO_WILDCARDS'''
* '''X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS'''

populate the X509_VERIFY_PARAMS with the desired hostname, and let the OpenSSL code call X509_check_host automatically.

This makes it easier to some day enable DANE TLSA support, because with DANE, name checks need to be skipped for DANE-EE(3) TLSA records, as the DNSSEC TLSA records provides the requisite name
binding instead.

Also with the X509_VERIFY_PARAM approach, name checks happen early, and for applications that don't continue handshakes with unauthenticated peers, terminate as early as possible.

There is an associated new X509 error code: '''X509_V_ERR_HOSTNAME_MISMATCH'''

== cUrl code ==

[https://github.com/iSECPartners/ssl-conservatory Here is some sample code] which shows how validating the hostname can be done. However, it does not handle wildcard certificates, so [http://archives.seul.org/libevent/users/Feb-2013/msg00043.html borrowing some code from cURL] might be one way to go.

for sake of simplicity i copied here the related code of last CURL reference :

<pre>
/* Obtained from: https://github.com/iSECPartners/ssl-conservatory */

/*
Copyright (C) 2012, iSEC Partners.

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
*/

/*
* Helper functions to perform basic hostname validation using OpenSSL.
*
* Please read "everything-you-wanted-to-know-about-openssl.pdf" before
* attempting to use this code. This whitepaper describes how the code works,
* how it should be used, and what its limitations are.
*
* Author: Alban Diquet
* License: See LICENSE
*
*/

// Get rid of OSX 10.7 and greater deprecation warnings.
#if defined(__APPLE__) && defined(__clang__)
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
#endif

#include <openssl/x509v3.h>
#include <openssl/ssl.h>

#include "openssl_hostname_validation.h"
#include "hostcheck.h"

#define HOSTNAME_MAX_SIZE 255

/**
* Tries to find a match for hostname in the certificate's Common Name field.
*
* Returns MatchFound if a match was found.
* Returns MatchNotFound if no matches were found.
* Returns MalformedCertificate if the Common Name had a NUL character embedded in it.
* Returns Error if the Common Name could not be extracted.
*/
static HostnameValidationResult matches_common_name(const char *hostname, const X509 *server_cert) {
int common_name_loc = -1;
X509_NAME_ENTRY *common_name_entry = NULL;
ASN1_STRING *common_name_asn1 = NULL;
char *common_name_str = NULL;

// Find the position of the CN field in the Subject field of the certificate
common_name_loc = X509_NAME_get_index_by_NID(X509_get_subject_name((X509 *) server_cert), NID_commonName, -1);
if (common_name_loc < 0) {
return Error;
}

// Extract the CN field
common_name_entry = X509_NAME_get_entry(X509_get_subject_name((X509 *) server_cert), common_name_loc);
if (common_name_entry == NULL) {
return Error;
}

// Convert the CN field to a C string
common_name_asn1 = X509_NAME_ENTRY_get_data(common_name_entry);
if (common_name_asn1 == NULL) {
return Error;
}
common_name_str = (char *) ASN1_STRING_data(common_name_asn1);

// Make sure there isn't an embedded NUL character in the CN
if ((size_t)ASN1_STRING_length(common_name_asn1) != strlen(common_name_str)) {
return MalformedCertificate;
}

// Compare expected hostname with the CN
if (Curl_cert_hostcheck(common_name_str, hostname) == CURL_HOST_MATCH) {
return MatchFound;
}
else {
return MatchNotFound;
}
}

/**
* Tries to find a match for hostname in the certificate's Subject Alternative Name extension.
*
* Returns MatchFound if a match was found.
* Returns MatchNotFound if no matches were found.
* Returns MalformedCertificate if any of the hostnames had a NUL character embedded in it.
* Returns NoSANPresent if the SAN extension was not present in the certificate.
*/
static HostnameValidationResult matches_subject_alternative_name(const char *hostname, const X509 *server_cert) {
HostnameValidationResult result = MatchNotFound;
int i;
int san_names_nb = -1;
STACK_OF(GENERAL_NAME) *san_names = NULL;

// Try to extract the names within the SAN extension from the certificate
san_names = X509_get_ext_d2i((X509 *) server_cert, NID_subject_alt_name, NULL, NULL);
if (san_names == NULL) {
return NoSANPresent;
}
san_names_nb = sk_GENERAL_NAME_num(san_names);

// Check each name within the extension
for (i=0; i<san_names_nb; i++) {
const GENERAL_NAME *current_name = sk_GENERAL_NAME_value(san_names, i);

if (current_name->type == GEN_DNS) {
// Current name is a DNS name, let's check it
char *dns_name = (char *) ASN1_STRING_data(current_name->d.dNSName);

// Make sure there isn't an embedded NUL character in the DNS name
if ((size_t)ASN1_STRING_length(current_name->d.dNSName) != strlen(dns_name)) {
result = MalformedCertificate;
break;
}
else { // Compare expected hostname with the DNS name
if (Curl_cert_hostcheck(dns_name, hostname)
== CURL_HOST_MATCH) {
result = MatchFound;
break;
}
}
}
}
sk_GENERAL_NAME_pop_free(san_names, GENERAL_NAME_free);

return result;
}

/**
* Validates the server's identity by looking for the expected hostname in the
* server's certificate. As described in RFC 6125, it first tries to find a match
* in the Subject Alternative Name extension. If the extension is not present in
* the certificate, it checks the Common Name instead.
*
* Returns MatchFound if a match was found.
* Returns MatchNotFound if no matches were found.
* Returns MalformedCertificate if any of the hostnames had a NUL character embedded in it.
* Returns Error if there was an error.
*/
HostnameValidationResult validate_hostname(const char *hostname, const X509 *server_cert) {
HostnameValidationResult result;

if((hostname == NULL) || (server_cert == NULL))
return Error;

// First try the Subject Alternative Names extension
result = matches_subject_alternative_name(hostname, server_cert);
if (result == NoSANPresent) {
// Extension was not found: try the Common Name
result = matches_common_name(hostname, server_cert);
}

return result;
}

</pre>

[[Category:SSL/TLS]]
[[Category:Common Mistake]]
[[Category:Examples]]

Hostname validation

2015-01-26T17:53:41Z

Philippe lhardy: updated content according to mailling list discussions

One [https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html very common mistake] made by users of OpenSSL is to assume that OpenSSL will validate the hostname in the server's certificate. Currently, it does not, although a future version (1.1.0?) will include this functionality.

== Recommendation ==

(extracted from mailling list discussion answer from Viktor Dukhovni)

Starting with 1.0.2 version use '''X509_check_host()''' [[X509_check_host]] interface

Wildcard support is configured via the flags documented for X509_check_host(), the two most frequently useful are:
* '''X509_CHECK_FLAG_NO_WILDCARDS'''
* '''X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS'''

populate the X509_VERIFY_PARAMS with the desired hostname, and let the OpenSSL code call X509_check_host automatically.

This makes it easier to some day enable DANE TLSA support, because with DANE, name checks need to be skipped for DANE-EE(3) TLSA records, as the DNSSEC TLSA records provides the requisite name
binding instead.

Also with the X509_VERIFY_PARAM approach, name checks happen early, and for applications that don't continue handshakes with unauthenticated peers, terminate as early as possible.

There is an associated new X509 error code: '''X509_V_ERR_HOSTNAME_MISMATCH'''

== cUrl code ==

[https://github.com/iSECPartners/ssl-conservatory Here is some sample code] which shows how validating the hostname can be done. However, it does not handle wildcard certificates, so [http://archives.seul.org/libevent/users/Feb-2013/msg00043.html borrowing some code from cURL] might be one way to go.

for sake of simplicity i copied here the related code of last CURL reference :

<pre>
/* Obtained from: https://github.com/iSECPartners/ssl-conservatory */

/*
Copyright (C) 2012, iSEC Partners.

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
*/

/*
* Helper functions to perform basic hostname validation using OpenSSL.
*
* Please read "everything-you-wanted-to-know-about-openssl.pdf" before
* attempting to use this code. This whitepaper describes how the code works,
* how it should be used, and what its limitations are.
*
* Author: Alban Diquet
* License: See LICENSE
*
*/

// Get rid of OSX 10.7 and greater deprecation warnings.
#if defined(__APPLE__) && defined(__clang__)
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
#endif

#include <openssl/x509v3.h>
#include <openssl/ssl.h>

#include "openssl_hostname_validation.h"
#include "hostcheck.h"

#define HOSTNAME_MAX_SIZE 255

/**
* Tries to find a match for hostname in the certificate's Common Name field.
*
* Returns MatchFound if a match was found.
* Returns MatchNotFound if no matches were found.
* Returns MalformedCertificate if the Common Name had a NUL character embedded in it.
* Returns Error if the Common Name could not be extracted.
*/
static HostnameValidationResult matches_common_name(const char *hostname, const X509 *server_cert) {
int common_name_loc = -1;
X509_NAME_ENTRY *common_name_entry = NULL;
ASN1_STRING *common_name_asn1 = NULL;
char *common_name_str = NULL;

// Find the position of the CN field in the Subject field of the certificate
common_name_loc = X509_NAME_get_index_by_NID(X509_get_subject_name((X509 *) server_cert), NID_commonName, -1);
if (common_name_loc < 0) {
return Error;
}

// Extract the CN field
common_name_entry = X509_NAME_get_entry(X509_get_subject_name((X509 *) server_cert), common_name_loc);
if (common_name_entry == NULL) {
return Error;
}

// Convert the CN field to a C string
common_name_asn1 = X509_NAME_ENTRY_get_data(common_name_entry);
if (common_name_asn1 == NULL) {
return Error;
}
common_name_str = (char *) ASN1_STRING_data(common_name_asn1);

// Make sure there isn't an embedded NUL character in the CN
if ((size_t)ASN1_STRING_length(common_name_asn1) != strlen(common_name_str)) {
return MalformedCertificate;
}

// Compare expected hostname with the CN
if (Curl_cert_hostcheck(common_name_str, hostname) == CURL_HOST_MATCH) {
return MatchFound;
}
else {
return MatchNotFound;
}
}

/**
* Tries to find a match for hostname in the certificate's Subject Alternative Name extension.
*
* Returns MatchFound if a match was found.
* Returns MatchNotFound if no matches were found.
* Returns MalformedCertificate if any of the hostnames had a NUL character embedded in it.
* Returns NoSANPresent if the SAN extension was not present in the certificate.
*/
static HostnameValidationResult matches_subject_alternative_name(const char *hostname, const X509 *server_cert) {
HostnameValidationResult result = MatchNotFound;
int i;
int san_names_nb = -1;
STACK_OF(GENERAL_NAME) *san_names = NULL;

// Try to extract the names within the SAN extension from the certificate
san_names = X509_get_ext_d2i((X509 *) server_cert, NID_subject_alt_name, NULL, NULL);
if (san_names == NULL) {
return NoSANPresent;
}
san_names_nb = sk_GENERAL_NAME_num(san_names);

// Check each name within the extension
for (i=0; i<san_names_nb; i++) {
const GENERAL_NAME *current_name = sk_GENERAL_NAME_value(san_names, i);

if (current_name->type == GEN_DNS) {
// Current name is a DNS name, let's check it
char *dns_name = (char *) ASN1_STRING_data(current_name->d.dNSName);

// Make sure there isn't an embedded NUL character in the DNS name
if ((size_t)ASN1_STRING_length(current_name->d.dNSName) != strlen(dns_name)) {
result = MalformedCertificate;
break;
}
else { // Compare expected hostname with the DNS name
if (Curl_cert_hostcheck(dns_name, hostname)
== CURL_HOST_MATCH) {
result = MatchFound;
break;
}
}
}
}
sk_GENERAL_NAME_pop_free(san_names, GENERAL_NAME_free);

return result;
}

/**
* Validates the server's identity by looking for the expected hostname in the
* server's certificate. As described in RFC 6125, it first tries to find a match
* in the Subject Alternative Name extension. If the extension is not present in
* the certificate, it checks the Common Name instead.
*
* Returns MatchFound if a match was found.
* Returns MatchNotFound if no matches were found.
* Returns MalformedCertificate if any of the hostnames had a NUL character embedded in it.
* Returns Error if there was an error.
*/
HostnameValidationResult validate_hostname(const char *hostname, const X509 *server_cert) {
HostnameValidationResult result;

if((hostname == NULL) || (server_cert == NULL))
return Error;

// First try the Subject Alternative Names extension
result = matches_subject_alternative_name(hostname, server_cert);
if (result == NoSANPresent) {
// Extension was not found: try the Common Name
result = matches_common_name(hostname, server_cert);
}

return result;
}

</pre>

[[Category:SSL/TLS]]
[[Category:Common Mistake]]
[[Category:Examples]]

SSL and TLS Protocols

2014-11-04T21:11:53Z

Philippe lhardy: /* No Authentication Aka Anonymous */

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly release). After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFCs.

OpenSSL provides an implementation for those protocols and is often used as the reference implementation for any new feature.

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets to be able to leverage security on existing TCP socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still draft.

Connectionless support is provided via DTLS.

Those protocols are configurable and can use various ciphers depending on their version.

== Security ==

Besides implementation problems leading to security issues, there is security inherent to the protocol itself.

It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommended to control protocol downgrade.

=== POODLE : SSLv3 harmful ===

[[SSL MODE SEND FALLBACK SCSV]]

=== versions tricks ===

==== SCSV ====

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems.
Its presence is used to signal some facts or contextual information allowing it to not break existing implementations that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3
Usage of a cipher suite value is explained by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
openssl : SSL3_CK_SCSV
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
openssl : SSL3_CK_FALLBACK_SCSV

== Handshake ==

A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and server that will be used to cipher the flow.

In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.

The initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

== Cipher Suites ==

* How cipher suites are negotiated ?

What TLS 1.2 rfc says :
<pre>
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions, this field is
the value from the state of the session being resumed.
</pre>

So basicaly server has the decision choice and does not provide a list of its own ciphersuites but just the selected one

What are best ciphersuites to choose ?

some interesting hint there : http://zombe.es/post/4078724716/openssl-cipher-selection

* Is there a normalized cipher suite ordering ?

not much more than what is told for 'How cipher suites are negotiated ?'

So it is implementation dependent. In openssl there are two modes:
** default is to choose the first compatible cipher suite from client hello.
** SSL_OP_CIPHER_SERVER_PREFERENCE to SSL_CTX_set_option to choose from server cipher list order.

* How to setup ciphersuites in openssl ?

[[Manual:SSL_CTX_set_cipher_list(3)]] where string cipher parameter is described in [[Manual:ciphers(1)]]

== Session Resumption ==

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake) allowing saving for both client and server CPU.

RFC 2246, section 7, p. 23

<pre>
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
</pre>

This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

( to obtain session from connection use function : [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )

== Renegotiation ==

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate :

a Client will send a '''ClientHello''' over its existing SSL connection

a Server will send a '''HelloRequest''' and expects Client to renegotiate with a ClientHello in very short time.

server renegotiation ( without resumption )
<pre>
# Given a SSL Connection con :
SSL *con;

SSL_renegotiate(con);
i=SSL_do_handshake(con);
</pre>

To use both renegotiation and resumption use : SSL_renegotiate_abbreviated(con) which won't request to recreate a new session ( since 1.0.1 ).

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''

== TLS Extensions ==

=== Server Name Indication ===

SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the client what Certificate the client expects to receive.

See how a C program can use [[Libssl API]] and provide SNI information with
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]

== Server Authentication ==

=== Server Certificate ===

This is '''Public Key''' Certified by a Certificate with Trust from client. Trust from client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]

=== No Authentication Aka Anonymous ===

Even if it look like is a strange idea, it is possible to select cipher suite that does not provide any server authentication but still provide confidentiality.

Selecting string cipher '''aNULL''' [[Manual:ciphers(1)]] allows to select such cipher suite. Remark this is not same a '''eNULL''' that provides no confidentiality at all.

Anonymous Diffie_Hellman exchange ('''DH''') and Anonymous Elliptic Curves Diffie Hellman Exchange ('''ECDH''') methods provide this anonymous authentication.

== Client Authentication ==

Client authentication is optional. in many cases client does not authenticaiton at ssl layer, but with usage of protocols above ssl by exemple with HTTP authenticate methods.

=== Client Certificates ===

* Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.

* Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).

* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

== Alternate Authentication Methods ==

=== Public Key Certificate ===

This is the most commonly used method. With X509 Certificates and Certficate Authorities.

It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

=== Pre-Shared Keys ===

TLS PSK Pre Shared Key

=== Kerberos ===

=== Password ===

TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.

Supported by OpenSSL with version 1.0.1.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.

It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

SSL and TLS Protocols

2014-11-04T21:10:39Z

Philippe lhardy: /* No Authentication Aka Anonymous */

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly release). After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFCs.

OpenSSL provides an implementation for those protocols and is often used as the reference implementation for any new feature.

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets to be able to leverage security on existing TCP socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still draft.

Connectionless support is provided via DTLS.

Those protocols are configurable and can use various ciphers depending on their version.

== Security ==

Besides implementation problems leading to security issues, there is security inherent to the protocol itself.

It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommended to control protocol downgrade.

=== POODLE : SSLv3 harmful ===

[[SSL MODE SEND FALLBACK SCSV]]

=== versions tricks ===

==== SCSV ====

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems.
Its presence is used to signal some facts or contextual information allowing it to not break existing implementations that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3
Usage of a cipher suite value is explained by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
openssl : SSL3_CK_SCSV
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
openssl : SSL3_CK_FALLBACK_SCSV

== Handshake ==

A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and server that will be used to cipher the flow.

In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.

The initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

== Cipher Suites ==

* How cipher suites are negotiated ?

What TLS 1.2 rfc says :
<pre>
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions, this field is
the value from the state of the session being resumed.
</pre>

So basicaly server has the decision choice and does not provide a list of its own ciphersuites but just the selected one

What are best ciphersuites to choose ?

some interesting hint there : http://zombe.es/post/4078724716/openssl-cipher-selection

* Is there a normalized cipher suite ordering ?

not much more than what is told for 'How cipher suites are negotiated ?'

So it is implementation dependent. In openssl there are two modes:
** default is to choose the first compatible cipher suite from client hello.
** SSL_OP_CIPHER_SERVER_PREFERENCE to SSL_CTX_set_option to choose from server cipher list order.

* How to setup ciphersuites in openssl ?

[[Manual:SSL_CTX_set_cipher_list(3)]] where string cipher parameter is described in [[Manual:ciphers(1)]]

== Session Resumption ==

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake) allowing saving for both client and server CPU.

RFC 2246, section 7, p. 23

<pre>
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
</pre>

This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

( to obtain session from connection use function : [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )

== Renegotiation ==

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate :

a Client will send a '''ClientHello''' over its existing SSL connection

a Server will send a '''HelloRequest''' and expects Client to renegotiate with a ClientHello in very short time.

server renegotiation ( without resumption )
<pre>
# Given a SSL Connection con :
SSL *con;

SSL_renegotiate(con);
i=SSL_do_handshake(con);
</pre>

To use both renegotiation and resumption use : SSL_renegotiate_abbreviated(con) which won't request to recreate a new session ( since 1.0.1 ).

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''

== TLS Extensions ==

=== Server Name Indication ===

SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the client what Certificate the client expects to receive.

See how a C program can use [[Libssl API]] and provide SNI information with
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]

== Server Authentication ==

=== Server Certificate ===

This is '''Public Key''' Certified by a Certificate with Trust from client. Trust from client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]

=== No Authentication Aka Anonymous ===

Even if it look like is a strange idea, it is possible to select cipher suite that does not provide any server authentication but still provide confidentiality.

Selecting string cipher '''aNULL''' [[Manual:ciphers(1)]] allows to select such cipher suite. Remark this is not same a '''eNULL''' that provides no confidentiality at all.

Anonymous Diffie_Hellman exchange and Anonymous Elliptic Curves Diffie Hellman Exchange methods provide this anonymous authentication.

== Client Authentication ==

Client authentication is optional. in many cases client does not authenticaiton at ssl layer, but with usage of protocols above ssl by exemple with HTTP authenticate methods.

=== Client Certificates ===

* Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.

* Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).

* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

== Alternate Authentication Methods ==

=== Public Key Certificate ===

This is the most commonly used method. With X509 Certificates and Certficate Authorities.

It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

=== Pre-Shared Keys ===

TLS PSK Pre Shared Key

=== Kerberos ===

=== Password ===

TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.

Supported by OpenSSL with version 1.0.1.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.

It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

SSL and TLS Protocols

2014-11-04T21:09:51Z

Philippe lhardy: /* Server Certificate */

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly release). After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFCs.

OpenSSL provides an implementation for those protocols and is often used as the reference implementation for any new feature.

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets to be able to leverage security on existing TCP socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still draft.

Connectionless support is provided via DTLS.

Those protocols are configurable and can use various ciphers depending on their version.

== Security ==

Besides implementation problems leading to security issues, there is security inherent to the protocol itself.

It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommended to control protocol downgrade.

=== POODLE : SSLv3 harmful ===

[[SSL MODE SEND FALLBACK SCSV]]

=== versions tricks ===

==== SCSV ====

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems.
Its presence is used to signal some facts or contextual information allowing it to not break existing implementations that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3
Usage of a cipher suite value is explained by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
openssl : SSL3_CK_SCSV
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
openssl : SSL3_CK_FALLBACK_SCSV

== Handshake ==

A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and server that will be used to cipher the flow.

In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.

The initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

== Cipher Suites ==

* How cipher suites are negotiated ?

What TLS 1.2 rfc says :
<pre>
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions, this field is
the value from the state of the session being resumed.
</pre>

So basicaly server has the decision choice and does not provide a list of its own ciphersuites but just the selected one

What are best ciphersuites to choose ?

some interesting hint there : http://zombe.es/post/4078724716/openssl-cipher-selection

* Is there a normalized cipher suite ordering ?

not much more than what is told for 'How cipher suites are negotiated ?'

So it is implementation dependent. In openssl there are two modes:
** default is to choose the first compatible cipher suite from client hello.
** SSL_OP_CIPHER_SERVER_PREFERENCE to SSL_CTX_set_option to choose from server cipher list order.

* How to setup ciphersuites in openssl ?

[[Manual:SSL_CTX_set_cipher_list(3)]] where string cipher parameter is described in [[Manual:ciphers(1)]]

== Session Resumption ==

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake) allowing saving for both client and server CPU.

RFC 2246, section 7, p. 23

<pre>
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
</pre>

This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

( to obtain session from connection use function : [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )

== Renegotiation ==

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate :

a Client will send a '''ClientHello''' over its existing SSL connection

a Server will send a '''HelloRequest''' and expects Client to renegotiate with a ClientHello in very short time.

server renegotiation ( without resumption )
<pre>
# Given a SSL Connection con :
SSL *con;

SSL_renegotiate(con);
i=SSL_do_handshake(con);
</pre>

To use both renegotiation and resumption use : SSL_renegotiate_abbreviated(con) which won't request to recreate a new session ( since 1.0.1 ).

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''

== TLS Extensions ==

=== Server Name Indication ===

SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the client what Certificate the client expects to receive.

See how a C program can use [[Libssl API]] and provide SNI information with
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]

== Server Authentication ==

=== Server Certificate ===

This is '''Public Key''' Certified by a Certificate with Trust from client. Trust from client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]

=== No Authentication Aka Anonymous ===

Even if it look like is a strange idea, it is possible to select cipher suite that does not provide any server authentication but still provide confidentiality.

Selecting string cipher 'aNULL' [[Manual:ciphers(1)]] allows to select such cipher suite. Remark this is not same a 'eNULL' that provides no confidentiality at all.

Anonymous Diffie_Hellman exchange and Anonymous Elliptic Curves Diffie Hellman Exchange methods provide this anonymous authentication.

== Client Authentication ==

Client authentication is optional. in many cases client does not authenticaiton at ssl layer, but with usage of protocols above ssl by exemple with HTTP authenticate methods.

=== Client Certificates ===

* Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.

* Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).

* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

== Alternate Authentication Methods ==

=== Public Key Certificate ===

This is the most commonly used method. With X509 Certificates and Certficate Authorities.

It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

=== Pre-Shared Keys ===

TLS PSK Pre Shared Key

=== Kerberos ===

=== Password ===

TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.

Supported by OpenSSL with version 1.0.1.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.

It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

SSL and TLS Protocols

2014-11-04T20:58:21Z

Philippe lhardy: /* Cipher Suites */

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly release). After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFCs.

OpenSSL provides an implementation for those protocols and is often used as the reference implementation for any new feature.

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets to be able to leverage security on existing TCP socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still draft.

Connectionless support is provided via DTLS.

Those protocols are configurable and can use various ciphers depending on their version.

== Security ==

Besides implementation problems leading to security issues, there is security inherent to the protocol itself.

It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommended to control protocol downgrade.

=== POODLE : SSLv3 harmful ===

[[SSL MODE SEND FALLBACK SCSV]]

=== versions tricks ===

==== SCSV ====

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems.
Its presence is used to signal some facts or contextual information allowing it to not break existing implementations that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3
Usage of a cipher suite value is explained by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
openssl : SSL3_CK_SCSV
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
openssl : SSL3_CK_FALLBACK_SCSV

== Handshake ==

A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and server that will be used to cipher the flow.

In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.

The initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

== Cipher Suites ==

* How cipher suites are negotiated ?

What TLS 1.2 rfc says :
<pre>
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions, this field is
the value from the state of the session being resumed.
</pre>

So basicaly server has the decision choice and does not provide a list of its own ciphersuites but just the selected one

What are best ciphersuites to choose ?

some interesting hint there : http://zombe.es/post/4078724716/openssl-cipher-selection

* Is there a normalized cipher suite ordering ?

not much more than what is told for 'How cipher suites are negotiated ?'

So it is implementation dependent. In openssl there are two modes:
** default is to choose the first compatible cipher suite from client hello.
** SSL_OP_CIPHER_SERVER_PREFERENCE to SSL_CTX_set_option to choose from server cipher list order.

* How to setup ciphersuites in openssl ?

[[Manual:SSL_CTX_set_cipher_list(3)]] where string cipher parameter is described in [[Manual:ciphers(1)]]

== Session Resumption ==

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake) allowing saving for both client and server CPU.

RFC 2246, section 7, p. 23

<pre>
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
</pre>

This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

( to obtain session from connection use function : [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )

== Renegotiation ==

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate :

a Client will send a '''ClientHello''' over its existing SSL connection

a Server will send a '''HelloRequest''' and expects Client to renegotiate with a ClientHello in very short time.

server renegotiation ( without resumption )
<pre>
# Given a SSL Connection con :
SSL *con;

SSL_renegotiate(con);
i=SSL_do_handshake(con);
</pre>

To use both renegotiation and resumption use : SSL_renegotiate_abbreviated(con) which won't request to recreate a new session ( since 1.0.1 ).

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''

== TLS Extensions ==

=== Server Name Indication ===

SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the client what Certificate the client expects to receive.

See how a C program can use [[Libssl API]] and provide SNI information with
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]

== Server Authentication ==

=== Server Certificate ===

This is '''Public Key''' Certified by a Certificate with Trust from client. Trust from client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]

== Client Authentication ==

Client authentication is optional. in many cases client does not authenticaiton at ssl layer, but with usage of protocols above ssl by exemple with HTTP authenticate methods.

=== Client Certificates ===

* Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.

* Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).

* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

== Alternate Authentication Methods ==

=== Public Key Certificate ===

This is the most commonly used method. With X509 Certificates and Certficate Authorities.

It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

=== Pre-Shared Keys ===

TLS PSK Pre Shared Key

=== Kerberos ===

=== Password ===

TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.

Supported by OpenSSL with version 1.0.1.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.

It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

SSL and TLS Protocols

2014-11-04T20:58:04Z

Philippe lhardy: /* Cipher Suites */

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly release). After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFCs.

OpenSSL provides an implementation for those protocols and is often used as the reference implementation for any new feature.

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets to be able to leverage security on existing TCP socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still draft.

Connectionless support is provided via DTLS.

Those protocols are configurable and can use various ciphers depending on their version.

== Security ==

Besides implementation problems leading to security issues, there is security inherent to the protocol itself.

It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommended to control protocol downgrade.

=== POODLE : SSLv3 harmful ===

[[SSL MODE SEND FALLBACK SCSV]]

=== versions tricks ===

==== SCSV ====

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems.
Its presence is used to signal some facts or contextual information allowing it to not break existing implementations that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3
Usage of a cipher suite value is explained by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
openssl : SSL3_CK_SCSV
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
openssl : SSL3_CK_FALLBACK_SCSV

== Handshake ==

A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and server that will be used to cipher the flow.

In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.

The initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

== Cipher Suites ==

* How cipher suites are negotiated ?

What TLS 1.2 rfc says :
<pre>
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions, this field is
the value from the state of the session being resumed.
</pre>

So basicaly server has the decision choice and does not provide a list of its own ciphersuites but just the selected one

What are best ciphersuites to choose ?

some interesting hint there : http://zombe.es/post/4078724716/openssl-cipher-selection

* Is there a normalized cipher suite ordering ?

not much more than what is told for 'How cipher suites are negotiated ?'

So it is implementation dependent. In openssl there are two modes:
* default is to choose the first compatible cipher suite from client hello.
* SSL_OP_CIPHER_SERVER_PREFERENCE to SSL_CTX_set_option to choose from server cipher list order.

* How to setup ciphersuites in openssl ?

[[Manual:SSL_CTX_set_cipher_list(3)]] where string cipher parameter is described in [[Manual:ciphers(1)]]

== Session Resumption ==

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake) allowing saving for both client and server CPU.

RFC 2246, section 7, p. 23

<pre>
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
</pre>

This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

( to obtain session from connection use function : [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )

== Renegotiation ==

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate :

a Client will send a '''ClientHello''' over its existing SSL connection

a Server will send a '''HelloRequest''' and expects Client to renegotiate with a ClientHello in very short time.

server renegotiation ( without resumption )
<pre>
# Given a SSL Connection con :
SSL *con;

SSL_renegotiate(con);
i=SSL_do_handshake(con);
</pre>

To use both renegotiation and resumption use : SSL_renegotiate_abbreviated(con) which won't request to recreate a new session ( since 1.0.1 ).

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''

== TLS Extensions ==

=== Server Name Indication ===

SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the client what Certificate the client expects to receive.

See how a C program can use [[Libssl API]] and provide SNI information with
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]

== Server Authentication ==

=== Server Certificate ===

This is '''Public Key''' Certified by a Certificate with Trust from client. Trust from client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]

== Client Authentication ==

Client authentication is optional. in many cases client does not authenticaiton at ssl layer, but with usage of protocols above ssl by exemple with HTTP authenticate methods.

=== Client Certificates ===

* Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.

* Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).

* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

== Alternate Authentication Methods ==

=== Public Key Certificate ===

This is the most commonly used method. With X509 Certificates and Certficate Authorities.

It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

=== Pre-Shared Keys ===

TLS PSK Pre Shared Key

=== Kerberos ===

=== Password ===

TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.

Supported by OpenSSL with version 1.0.1.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.

It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

SSL and TLS Protocols

2014-11-04T18:07:55Z

Philippe lhardy: /* Cipher Suites */

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly release). After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFCs.

OpenSSL provides an implementation for those protocols and is often used as the reference implementation for any new feature.

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets to be able to leverage security on existing TCP socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still draft.

Connectionless support is provided via DTLS.

Those protocols are configurable and can use various ciphers depending on their version.

== Security ==

Besides implementation problems leading to security issues, there is security inherent to the protocol itself.

It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommended to control protocol downgrade.

=== POODLE : SSLv3 harmful ===

[[SSL MODE SEND FALLBACK SCSV]]

=== versions tricks ===

==== SCSV ====

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems.
Its presence is used to signal some facts or contextual information allowing it to not break existing implementations that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3
Usage of a cipher suite value is explained by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
openssl : SSL3_CK_SCSV
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
openssl : SSL3_CK_FALLBACK_SCSV

== Handshake ==

A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and server that will be used to cipher the flow.

In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.

The initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

== Cipher Suites ==

* How cipher suites are negotiated ?

What TLS 1.2 rfc says :
<pre>
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions, this field is
the value from the state of the session being resumed.
</pre>

So basicaly server has the decision choice and does not provide a list of its own ciphersuites but just the selected one

What are best ciphersuites to choose ?

some interesting hint there : http://zombe.es/post/4078724716/openssl-cipher-selection

* Is there a normalized cipher suite ordering ?

not much more than what is told for 'How cipher suites are negotiated ?'

So it is implementation dependent. In openssl there are two modes:
* default is to choose the first compatible cipher suite from client hello.
* SSL_OP_CIPHER_SERVER_PREFERENCE to SSL_CTX_set_option to choose from server cipher list order.

== Session Resumption ==

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake) allowing saving for both client and server CPU.

RFC 2246, section 7, p. 23

<pre>
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
</pre>

This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

( to obtain session from connection use function : [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )

== Renegotiation ==

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate :

a Client will send a '''ClientHello''' over its existing SSL connection

a Server will send a '''HelloRequest''' and expects Client to renegotiate with a ClientHello in very short time.

server renegotiation ( without resumption )
<pre>
# Given a SSL Connection con :
SSL *con;

SSL_renegotiate(con);
i=SSL_do_handshake(con);
</pre>

To use both renegotiation and resumption use : SSL_renegotiate_abbreviated(con) which won't request to recreate a new session ( since 1.0.1 ).

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''

== TLS Extensions ==

=== Server Name Indication ===

SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the client what Certificate the client expects to receive.

See how a C program can use [[Libssl API]] and provide SNI information with
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]

== Server Authentication ==

=== Server Certificate ===

This is '''Public Key''' Certified by a Certificate with Trust from client. Trust from client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]

== Client Authentication ==

Client authentication is optional. in many cases client does not authenticaiton at ssl layer, but with usage of protocols above ssl by exemple with HTTP authenticate methods.

=== Client Certificates ===

* Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.

* Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).

* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

== Alternate Authentication Methods ==

=== Public Key Certificate ===

This is the most commonly used method. With X509 Certificates and Certficate Authorities.

It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

=== Pre-Shared Keys ===

TLS PSK Pre Shared Key

=== Kerberos ===

=== Password ===

TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.

Supported by OpenSSL with version 1.0.1.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.

It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

SSL and TLS Protocols

2014-11-04T17:56:02Z

Philippe lhardy: /* Cipher Suites */

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly release). After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFCs.

OpenSSL provides an implementation for those protocols and is often used as the reference implementation for any new feature.

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets to be able to leverage security on existing TCP socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still draft.

Connectionless support is provided via DTLS.

Those protocols are configurable and can use various ciphers depending on their version.

== Security ==

Besides implementation problems leading to security issues, there is security inherent to the protocol itself.

It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommended to control protocol downgrade.

=== POODLE : SSLv3 harmful ===

[[SSL MODE SEND FALLBACK SCSV]]

=== versions tricks ===

==== SCSV ====

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems.
Its presence is used to signal some facts or contextual information allowing it to not break existing implementations that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3
Usage of a cipher suite value is explained by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
openssl : SSL3_CK_SCSV
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
openssl : SSL3_CK_FALLBACK_SCSV

== Handshake ==

A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and server that will be used to cipher the flow.

In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.

The initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

== Cipher Suites ==

How cipher suites are negotiated ?

What are best ciphersuites to choose ?

some interesting hint there : http://zombe.es/post/4078724716/openssl-cipher-selection

* Is there a normalized cipher suite ordering ?

What TLS 1.2 rfc says :
<pre>
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions, this field is
the value from the state of the session being resumed.
</pre>

not much.

== Session Resumption ==

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake) allowing saving for both client and server CPU.

RFC 2246, section 7, p. 23

<pre>
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
</pre>

This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

( to obtain session from connection use function : [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )

== Renegotiation ==

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate :

a Client will send a '''ClientHello''' over its existing SSL connection

a Server will send a '''HelloRequest''' and expects Client to renegotiate with a ClientHello in very short time.

server renegotiation ( without resumption )
<pre>
# Given a SSL Connection con :
SSL *con;

SSL_renegotiate(con);
i=SSL_do_handshake(con);
</pre>

To use both renegotiation and resumption use : SSL_renegotiate_abbreviated(con) which won't request to recreate a new session ( since 1.0.1 ).

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''

== TLS Extensions ==

=== Server Name Indication ===

SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the client what Certificate the client expects to receive.

See how a C program can use [[Libssl API]] and provide SNI information with
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]

== Server Authentication ==

=== Server Certificate ===

This is '''Public Key''' Certified by a Certificate with Trust from client. Trust from client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]

== Client Authentication ==

Client authentication is optional. in many cases client does not authenticaiton at ssl layer, but with usage of protocols above ssl by exemple with HTTP authenticate methods.

=== Client Certificates ===

* Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.

* Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).

* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

== Alternate Authentication Methods ==

=== Public Key Certificate ===

This is the most commonly used method. With X509 Certificates and Certficate Authorities.

It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

=== Pre-Shared Keys ===

TLS PSK Pre Shared Key

=== Kerberos ===

=== Password ===

TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.

Supported by OpenSSL with version 1.0.1.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.

It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

SSL and TLS Protocols

2014-11-04T17:48:42Z

Philippe lhardy: /* Handshake */

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly release). After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFCs.

OpenSSL provides an implementation for those protocols and is often used as the reference implementation for any new feature.

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets to be able to leverage security on existing TCP socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still draft.

Connectionless support is provided via DTLS.

Those protocols are configurable and can use various ciphers depending on their version.

== Security ==

Besides implementation problems leading to security issues, there is security inherent to the protocol itself.

It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommended to control protocol downgrade.

=== POODLE : SSLv3 harmful ===

[[SSL MODE SEND FALLBACK SCSV]]

=== versions tricks ===

==== SCSV ====

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems.
Its presence is used to signal some facts or contextual information allowing it to not break existing implementations that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3
Usage of a cipher suite value is explained by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
openssl : SSL3_CK_SCSV
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
openssl : SSL3_CK_FALLBACK_SCSV

== Handshake ==

A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and server that will be used to cipher the flow.

In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.

The initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

== Cipher Suites ==

How cipher suites are negotiated ?

What are best ciphersuites to choose ?

some interesting hint there : http://zombe.es/post/4078724716/openssl-cipher-selection

== Session Resumption ==

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake) allowing saving for both client and server CPU.

RFC 2246, section 7, p. 23

<pre>
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
</pre>

This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

( to obtain session from connection use function : [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )

== Renegotiation ==

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate :

a Client will send a '''ClientHello''' over its existing SSL connection

a Server will send a '''HelloRequest''' and expects Client to renegotiate with a ClientHello in very short time.

server renegotiation ( without resumption )
<pre>
# Given a SSL Connection con :
SSL *con;

SSL_renegotiate(con);
i=SSL_do_handshake(con);
</pre>

To use both renegotiation and resumption use : SSL_renegotiate_abbreviated(con) which won't request to recreate a new session ( since 1.0.1 ).

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''

== TLS Extensions ==

=== Server Name Indication ===

SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the client what Certificate the client expects to receive.

See how a C program can use [[Libssl API]] and provide SNI information with
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]

== Server Authentication ==

=== Server Certificate ===

This is '''Public Key''' Certified by a Certificate with Trust from client. Trust from client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]

== Client Authentication ==

Client authentication is optional. in many cases client does not authenticaiton at ssl layer, but with usage of protocols above ssl by exemple with HTTP authenticate methods.

=== Client Certificates ===

* Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.

* Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).

* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

== Alternate Authentication Methods ==

=== Public Key Certificate ===

This is the most commonly used method. With X509 Certificates and Certficate Authorities.

It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

=== Pre-Shared Keys ===

TLS PSK Pre Shared Key

=== Kerberos ===

=== Password ===

TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.

Supported by OpenSSL with version 1.0.1.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.

It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

BIO

2014-11-01T07:37:30Z

Philippe lhardy: /* Combining Filters and Source Sink BIOs */

A BIO is an I/O stream abstraction; essentially OpenSSL's answer to the C library's <code>FILE *</code>. OpenSSL comes with a number of useful BIO types predefined, or you can create your own.

BIOs come in two flavors: source/sink, or filter. BIOs can be chained together. Each chain always has exactly one source/sink, but can have any number (zero or more) of filters.

Reading from a BIO can be done with [[Manual:BIO_read(3)]] and <code>BIO_gets</code>.

Writing to a BIO can be done with <code>BIO_write</code>, <code>BIO_puts</code>, <code>BIO_printf</code>, and <code>BIO_vprintf</code>.

== Filter BIOs ==

* [[Manual:BIO_f_base64(3)]]
* [[Manual:BIO_f_buffer(3)]]
* [[Manual:BIO_f_cipher(3)]]
* [[Manual:BIO_f_md(3)]]
* [[Manual:BIO_f_ssl(3)]]

== Source/sink BIOs ==

* [[Manual:BIO_s_accept(3)]]
* [[Manual:BIO_s_bio(3)]]
* [[Manual:BIO_s_connect(3)]]
* [[Manual:BIO_s_fd(3)]]
* [[Manual:BIO_s_file(3)]]
* [[Manual:BIO_s_mem(3)]]
* [[Manual:BIO_s_null(3)]]
* [[Manual:BIO_s_socket(3)]]

implementation of those bio are within bio/bss_xxx.c bss stading for Bio Source Sink

== Combining Filters and Source Sink BIOs ==

* [[Manual:BIO_push(3)]]

new_head = BIO_push(BIO * local_head, BIO * tail)

will connect tail at end of local_head chain.

WARNING BIO_push will never fail, but can create invalid chains.

In standard usage end of a chain is a source sink, and all other elements are filters.

* [[Manual:BIO_s_bio(3)]]

two separated BIOs can then be connected with BIO_make_bio_pair() into a connected pair.

BIO

2014-10-31T22:02:54Z

Philippe lhardy: /* Combining Filters and Source Sink BIOs */

A BIO is an I/O stream abstraction; essentially OpenSSL's answer to the C library's <code>FILE *</code>. OpenSSL comes with a number of useful BIO types predefined, or you can create your own.

BIOs come in two flavors: source/sink, or filter. BIOs can be chained together. Each chain always has exactly one source/sink, but can have any number (zero or more) of filters.

Reading from a BIO can be done with [[Manual:BIO_read(3)]] and <code>BIO_gets</code>.

Writing to a BIO can be done with <code>BIO_write</code>, <code>BIO_puts</code>, <code>BIO_printf</code>, and <code>BIO_vprintf</code>.

== Filter BIOs ==

* [[Manual:BIO_f_base64(3)]]
* [[Manual:BIO_f_buffer(3)]]
* [[Manual:BIO_f_cipher(3)]]
* [[Manual:BIO_f_md(3)]]
* [[Manual:BIO_f_ssl(3)]]

== Source/sink BIOs ==

* [[Manual:BIO_s_accept(3)]]
* [[Manual:BIO_s_bio(3)]]
* [[Manual:BIO_s_connect(3)]]
* [[Manual:BIO_s_fd(3)]]
* [[Manual:BIO_s_file(3)]]
* [[Manual:BIO_s_mem(3)]]
* [[Manual:BIO_s_null(3)]]
* [[Manual:BIO_s_socket(3)]]

implementation of those bio are within bio/bss_xxx.c bss stading for Bio Source Sink

== Combining Filters and Source Sink BIOs ==

* [[Manual:BIO_push(3)]]

new_head = BIO_push(BIO * local_head, BIO * tail)

will connect tail at end of local_head chain.

WARNING BIO_push will never fail, but can create invalid chains.

In standard usage end of a chain is a source sink, and all other elements are filters.

* [[Manual:BIO_s_bio(3)]]

Provide a way to combine half of one source sink with half of another to make sink communicate with source of the other.

two separated BIOs can then be connected with BIO_make_bio_pair() into a connected pair.

BIO

2014-10-31T21:39:05Z

Philippe lhardy: /* Combining Filters and Source Sink BIOs */

BIO

2014-10-31T21:31:56Z

Philippe lhardy: /* Combining Filters and Source Sink BIOS */

BIO

2014-10-31T21:17:31Z

Philippe lhardy: /* Combining Filters and Source Sink BIOS */

A BIO is an I/O stream abstraction; essentially OpenSSL's answer to the C library's <code>FILE *</code>. OpenSSL comes with a number of useful BIO types predefined, or you can create your own.

BIOs come in two flavors: source/sink, or filter. BIOs can be chained together. Each chain always has exactly one source/sink, but can have any number (zero or more) of filters.

Reading from a BIO can be done with [[Manual:BIO_read(3)]] and <code>BIO_gets</code>.

Writing to a BIO can be done with <code>BIO_write</code>, <code>BIO_puts</code>, <code>BIO_printf</code>, and <code>BIO_vprintf</code>.

== Filter BIOs ==

* [[Manual:BIO_f_base64(3)]]
* [[Manual:BIO_f_buffer(3)]]
* [[Manual:BIO_f_cipher(3)]]
* [[Manual:BIO_f_md(3)]]
* [[Manual:BIO_f_ssl(3)]]

== Source/sink BIOs ==

* [[Manual:BIO_s_accept(3)]]
* [[Manual:BIO_s_bio(3)]]
* [[Manual:BIO_s_connect(3)]]
* [[Manual:BIO_s_fd(3)]]
* [[Manual:BIO_s_file(3)]]
* [[Manual:BIO_s_mem(3)]]
* [[Manual:BIO_s_null(3)]]
* [[Manual:BIO_s_socket(3)]]

implementation of those bio are within bio/bss_xxx.c bss stading for Bio Source Sink

== Combining Filters and Source Sink BIOS ==

* [[Manual:BIO_push(3)]]

new_head = BIO_push(BIO * local_head, BIO * tail)

will connect tail at end of local_head chain.

WARNING BIO_push will never fail, but can create totaly invalid chains.

BIO

2014-10-31T21:16:27Z

Philippe lhardy: /* Source/sink BIOs */

A BIO is an I/O stream abstraction; essentially OpenSSL's answer to the C library's <code>FILE *</code>. OpenSSL comes with a number of useful BIO types predefined, or you can create your own.

BIOs come in two flavors: source/sink, or filter. BIOs can be chained together. Each chain always has exactly one source/sink, but can have any number (zero or more) of filters.

Reading from a BIO can be done with [[Manual:BIO_read(3)]] and <code>BIO_gets</code>.

Writing to a BIO can be done with <code>BIO_write</code>, <code>BIO_puts</code>, <code>BIO_printf</code>, and <code>BIO_vprintf</code>.

== Filter BIOs ==

* [[Manual:BIO_f_base64(3)]]
* [[Manual:BIO_f_buffer(3)]]
* [[Manual:BIO_f_cipher(3)]]
* [[Manual:BIO_f_md(3)]]
* [[Manual:BIO_f_ssl(3)]]

== Source/sink BIOs ==

* [[Manual:BIO_s_accept(3)]]
* [[Manual:BIO_s_bio(3)]]
* [[Manual:BIO_s_connect(3)]]
* [[Manual:BIO_s_fd(3)]]
* [[Manual:BIO_s_file(3)]]
* [[Manual:BIO_s_mem(3)]]
* [[Manual:BIO_s_null(3)]]
* [[Manual:BIO_s_socket(3)]]

implementation of those bio are within bio/bss_xxx.c bss stading for Bio Source Sink

== Combining Filters and Source Sink BIOS ==

* [[Manual:BIO_push(2)]]

new_head = BIO_push(BIO * local_head, BIO * tail)

will connect tail at end of local_head chain.

WARNING BIO_push will never fail, but can create totaly invalid chains.

SSL and TLS Protocols

2014-10-30T18:07:22Z

Philippe lhardy: /* Renegotiation */

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly release). After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFCs.

OpenSSL provides an implementation for those protocols and is often used as the reference implementation for any new feature.

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets to be able to leverage security on existing TCP socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still draft.

Connectionless support is provided via DTLS.

Those protocols are configurable and can use various ciphers depending on their version.

== Security ==

Besides implementation problems leading to security issues, there is security inherent to the protocol itself.

It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommended to control protocol downgrade.

=== POODLE : SSLv3 harmful ===

[[SSL MODE SEND FALLBACK SCSV]]

=== versions tricks ===

==== SCSV ====

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems.
Its presence is used to signal some facts or contextual information allowing it to not break existing implementations that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3
Usage of a cipher suite value is explained by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
openssl : SSL3_CK_SCSV
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
openssl : SSL3_CK_FALLBACK_SCSV

== Handshake ==

A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and server that will be used to cipher the flow.

In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.

The initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

== Session Resumption ==

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake) allowing saving for both client and server CPU.

RFC 2246, section 7, p. 23

<pre>
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
</pre>

This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

( to obtain session from connection use function : [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )

== Renegotiation ==

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate :

a Client will send a '''ClientHello''' over its existing SSL connection

a Server will send a '''HelloRequest''' and expects Client to renegotiate with a ClientHello in very short time.

server renegotiation ( without resumption )
<pre>
# Given a SSL Connection con :
SSL *con;

SSL_renegotiate(con);
i=SSL_do_handshake(con);
</pre>

To use both renegotiation and resumption use : SSL_renegotiate_abbreviated(con) which won't request to recreate a new session ( since 1.0.1 ).

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''

== TLS Extensions ==

=== Server Name Indication ===

SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the client what Certificate the client expects to receive.

See how a C program can use [[Libssl API]] and provide SNI information with
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]

== Server Authentication ==

=== Server Certificate ===

This is '''Public Key''' Certified by a Certificate with Trust from client. Trust from client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]

== Client Authentication ==

Client authentication is optional. in many cases client does not authenticaiton at ssl layer, but with usage of protocols above ssl by exemple with HTTP authenticate methods.

=== Client Certificates ===

* Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.

* Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).

* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

== Alternate Authentication Methods ==

=== Public Key Certificate ===

This is the most commonly used method. With X509 Certificates and Certficate Authorities.

It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

=== Pre-Shared Keys ===

TLS PSK Pre Shared Key

=== Kerberos ===

=== Password ===

TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.

Supported by OpenSSL with version 1.0.1.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.

It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

SSL and TLS Protocols

2014-10-28T17:52:11Z

Philippe lhardy: /* Renegotiation */

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly release). After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFCs.

OpenSSL provides an implementation for those protocols and is often used as the reference implementation for any new feature.

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets to be able to leverage security on existing TCP socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still draft.

Connectionless support is provided via DTLS.

Those protocols are configurable and can use various ciphers depending on their version.

== Security ==

Besides implementation problems leading to security issues, there is security inherent to the protocol itself.

It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommended to control protocol downgrade.

=== POODLE : SSLv3 harmful ===

[[SSL MODE SEND FALLBACK SCSV]]

=== versions tricks ===

==== SCSV ====

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems.
Its presence is used to signal some facts or contextual information allowing it to not break existing implementations that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3
Usage of a cipher suite value is explained by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
openssl : SSL3_CK_SCSV
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
openssl : SSL3_CK_FALLBACK_SCSV

== Handshake ==

A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and server that will be used to cipher the flow.

In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.

The initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

== Session Resumption ==

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake) allowing saving for both client and server CPU.

RFC 2246, section 7, p. 23

<pre>
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
</pre>

This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

( to obtain session from connection use function : [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )

== Renegotiation ==

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate :

a Client will send a '''ClientHello''' over its existing SSL connection

a Server will send a '''HelloRequest''' and expects Client to renegotiate with a ClientHello in very short time.

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''

== TLS Extensions ==

=== Server Name Indication ===

SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the client what Certificate the client expects to receive.

See how a C program can use [[Libssl API]] and provide SNI information with
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]

== Server Authentication ==

=== Server Certificate ===

This is '''Public Key''' Certified by a Certificate with Trust from client. Trust from client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]

== Client Authentication ==

Client authentication is optional. in many cases client does not authenticaiton at ssl layer, but with usage of protocols above ssl by exemple with HTTP authenticate methods.

=== Client Certificates ===

* Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.

* Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).

* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

== Alternate Authentication Methods ==

=== Public Key Certificate ===

This is the most commonly used method. With X509 Certificates and Certficate Authorities.

It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

=== Pre-Shared Keys ===

TLS PSK Pre Shared Key

=== Kerberos ===

=== Password ===

TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.

Supported by OpenSSL with version 1.0.1.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.

It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

SSL and TLS Protocols

2014-10-28T17:48:40Z

Philippe lhardy: /* Renegotiation */

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly release). After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFCs.

OpenSSL provides an implementation for those protocols and is often used as the reference implementation for any new feature.

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets to be able to leverage security on existing TCP socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still draft.

Connectionless support is provided via DTLS.

Those protocols are configurable and can use various ciphers depending on their version.

== Security ==

Besides implementation problems leading to security issues, there is security inherent to the protocol itself.

It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommended to control protocol downgrade.

=== POODLE : SSLv3 harmful ===

[[SSL MODE SEND FALLBACK SCSV]]

=== versions tricks ===

==== SCSV ====

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems.
Its presence is used to signal some facts or contextual information allowing it to not break existing implementations that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3
Usage of a cipher suite value is explained by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
openssl : SSL3_CK_SCSV
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
openssl : SSL3_CK_FALLBACK_SCSV

== Handshake ==

A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and server that will be used to cipher the flow.

In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.

The initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

== Session Resumption ==

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake) allowing saving for both client and server CPU.

RFC 2246, section 7, p. 23

<pre>
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
</pre>

This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

( to obtain session from connection use function : [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )

== Renegotiation ==

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate a Client will send a '''ClientHello''' over its existing SSL connection; a Server will send a '''HelloRequest'''

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''

== TLS Extensions ==

=== Server Name Indication ===

SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the client what Certificate the client expects to receive.

See how a C program can use [[Libssl API]] and provide SNI information with
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]

== Server Authentication ==

=== Server Certificate ===

This is '''Public Key''' Certified by a Certificate with Trust from client. Trust from client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]

== Client Authentication ==

Client authentication is optional. in many cases client does not authenticaiton at ssl layer, but with usage of protocols above ssl by exemple with HTTP authenticate methods.

=== Client Certificates ===

* Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.

* Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).

* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

== Alternate Authentication Methods ==

=== Public Key Certificate ===

This is the most commonly used method. With X509 Certificates and Certficate Authorities.

It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

=== Pre-Shared Keys ===

TLS PSK Pre Shared Key

=== Kerberos ===

=== Password ===

TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.

Supported by OpenSSL with version 1.0.1.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.

It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

SSL and TLS Protocols

2014-10-28T17:28:37Z

Philippe lhardy: /* Public Key Certificate */

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly release). After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFCs.

OpenSSL provides an implementation for those protocols and is often used as the reference implementation for any new feature.

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets to be able to leverage security on existing TCP socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still draft.

Connectionless support is provided via DTLS.

Those protocols are configurable and can use various ciphers depending on their version.

== Security ==

Besides implementation problems leading to security issues, there is security inherent to the protocol itself.

It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommended to control protocol downgrade.

=== POODLE : SSLv3 harmful ===

[[SSL MODE SEND FALLBACK SCSV]]

=== versions tricks ===

==== SCSV ====

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems.
Its presence is used to signal some facts or contextual information allowing it to not break existing implementations that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3
Usage of a cipher suite value is explained by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
openssl : SSL3_CK_SCSV
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
openssl : SSL3_CK_FALLBACK_SCSV

== Handshake ==

A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and server that will be used to cipher the flow.

In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.

The initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

== Session Resumption ==

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake) allowing saving for both client and server CPU.

RFC 2246, section 7, p. 23

<pre>
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
</pre>

This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

( to obtain session from connection use function : [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )

== Renegotiation ==

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate a Client will send a '''ClientHello''' over its existing SSL connection; a Server will send a '''ServerHello'''

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''

== TLS Extensions ==

=== Server Name Indication ===

SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].

Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the client what Certificate the client expects to receive.

See how a C program can use [[Libssl API]] and provide SNI information with
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]

== Server Authentication ==

=== Server Certificate ===

This is '''Public Key''' Certified by a Certificate with Trust from client. Trust from client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]

== Client Authentication ==

Client authentication is optional. in many cases client does not authenticaiton at ssl layer, but with usage of protocols above ssl by exemple with HTTP authenticate methods.

=== Client Certificates ===

* Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )
Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by the client to select the Client Certificate it will send.

* Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)
Client send its Client Certificate first then all intermediate Certificates, if any, up to the CA ( optionally excluded ).

* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

== Alternate Authentication Methods ==

=== Public Key Certificate ===

This is the most commonly used method. With X509 Certificates and Certficate Authorities.

It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

=== Pre-Shared Keys ===

TLS PSK Pre Shared Key

=== Kerberos ===

=== Password ===

TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.

Supported by OpenSSL with version 1.0.1.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.

It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

OpenSSLWiki - User contributions [en]

Simple TLS Client

Simple TLS Client

SSL/TLS Client

Talk:Simple TLS Client

Simple TLS Client

Simple TLS Client

Simple TLS Server

Talk:Command Line Utilities

Talk:Command Line Utilities

Mailing Lists

Base64

Base64

DER

DER

File:BIO f md filter.png

Base64

History And People

History And People

History And People

History And People

OpenSSL Overview

Compilation and Installation

Hostname validation

Hostname validation

Hostname validation

Hostname validation

Related Links

Related Links

Related Links

Related Links

Related Links

Related Links

SSL and TLS Protocols

SSL and TLS Protocols

SSL and TLS Protocols

SSL and TLS Protocols

SSL and TLS Protocols

SSL and TLS Protocols

SSL and TLS Protocols

SSL and TLS Protocols

BIO

BIO

BIO

BIO

BIO

BIO

SSL and TLS Protocols

SSL and TLS Protocols

SSL and TLS Protocols

SSL and TLS Protocols