mirrors/haproxy
1
0
Fork 0
mirror of https://git.haproxy.org/git/haproxy.git/ synced 2025-08-06 23:27:04 +02:00
Code Issues Projects Releases Wiki Activity

DOC: ssl: req_ssl_sni needs implicit TLS

Browse Source 
req_ssl_sni is not compatible with protocols negotiating TLS
explicitly, like SMTP on port 25 or 587 and IMAP on port 143.

Fix an example referring to 587 (SMTPS port with implicit TLS
is 465) and amend the req_ssl_sni documentation.

This doc fix should be backported to supported versions.
This commit is contained in:
Lukas Tribus 2020-07-19 00:25:06 +02:00 committed by Willy Tarreau
parent e732cbd8a9
commit a267b5df4a
1 changed files with 13 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
doc/configuration.txt
View File

@ -12259,15 +12259,16 @@ use-server <server> unless <condition>
The "use-server" statement works both in HTTP and TCP mode. This makes it The "use-server" statement works both in HTTP and TCP mode. This makes it
suitable for use with content-based inspection. For instance, a server could suitable for use with content-based inspection. For instance, a server could
be selected in a farm according to the TLS SNI field. And if these servers be selected in a farm according to the TLS SNI field when using protocols with
have their weight set to zero, they will not be used for other traffic. implicit TLS (also see "req_ssl_sni"). And if these servers have their weight
set to zero, they will not be used for other traffic.
Example : Example :
# intercept incoming TLS requests based on the SNI field # intercept incoming TLS requests based on the SNI field
use-server www if { req_ssl_sni -i www.example.com } use-server www if { req_ssl_sni -i www.example.com }
server www 192.168.0.1:443 weight 0 server www 192.168.0.1:443 weight 0
use-server mail if { req_ssl_sni -i mail.example.com } use-server mail if { req_ssl_sni -i mail.example.com }
server mail 192.168.0.1:587 weight 0 server mail 192.168.0.1:465 weight 0
use-server imap if { req_ssl_sni -i imap.example.com } use-server imap if { req_ssl_sni -i imap.example.com }
server imap 192.168.0.1:993 weight 0 server imap 192.168.0.1:993 weight 0
# all the rest is forwarded to this server # all the rest is forwarded to this server
@ -17670,13 +17671,15 @@ req_ssl_sni : string (deprecated)
contains data that parse as a complete SSL (v3 or superior) client hello contains data that parse as a complete SSL (v3 or superior) client hello
message. Note that this only applies to raw contents found in the request message. Note that this only applies to raw contents found in the request
buffer and not to contents deciphered via an SSL data layer, so this will not buffer and not to contents deciphered via an SSL data layer, so this will not
work with "bind" lines having the "ssl" option. SNI normally contains the work with "bind" lines having the "ssl" option. This will only work for actual
name of the host the client tries to connect to (for recent browsers). SNI is implicit TLS based protocols like HTTPS (443), IMAPS (993), SMTPS (465),
useful for allowing or denying access to certain hosts when SSL/TLS is used however it will not work for explicit TLS based protocols, like SMTP (25/587)
by the client. This test was designed to be used with TCP request content or IMAP (143). SNI normally contains the name of the host the client tries to
inspection. If content switching is needed, it is recommended to first wait connect to (for recent browsers). SNI is useful for allowing or denying access
for a complete client hello (type 1), like in the example below. See also to certain hosts when SSL/TLS is used by the client. This test was designed to
"ssl_fc_sni". be used with TCP request content inspection. If content switching is needed,
it is recommended to first wait for a complete client hello (type 1), like in
the example below. See also "ssl_fc_sni".
ACL derivatives : ACL derivatives :
req_ssl_sni : exact string match req_ssl_sni : exact string match