[squid-users] SSL options on different http_port resolving into a single config for all ports

[Amos Jeffries]

On 31/07/17 19:27, Wahaj Ali wrote:
> Thanks for the reply, Amos. A few follow up questions:
> 
> 1) Setting dynamic_cert_mem_cache_size=0 does solve the issue. However, 
> I fail to understand why caching the cert allows the connection to 
> continue on SSLv3, on a port that I've disabled it. Isn't cert exchange 
> done after the protocol has been selected. I don't think curl is 
> rejecting the cert, but rather the ssl connection fails to establish 
> before the cert exchange, since I also tried with the following command, 
> which ignores cert errors:
> > curl -k -vv -x https://127.0.0.1:3128 https://uatmail02.cimb.com -ssl3
> 

Are you referring to the -k ?

That option disables security validation procedures for the cert keys - 
like Squid's DONT_VERIFY_PEER option. That is all.

It cannot prevent OpenSSL *parsing* the cert and rejecting it on grounds 
that TLS-only things are being used on an SSLv3 connection, or SSL 
things are being on a TLS-only connection.


> 
> root at madmin-VirtualBox:/home/madmin/# curl -k -vv -x 
> https://127.0.0.1:3128 https://uatmail02.cimb.com -ssl3
> * About to connect() to proxy 127.0.0.1 port 3128 (#0)
> *   Trying 127.0.0.1... connected
> * Establish HTTP proxy tunnel to uatmail02.cimb.com:443
>  > CONNECT uatmail02.cimb.com:443 HTTP/1.1
>  > Host: uatmail02.cimb.com:443
>  > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 
> OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
>  > Proxy-Connection: Keep-Alive
>  >
> < HTTP/1.1 200 Connection established
> <
> * Proxy replied OK to CONNECT request
> * successfully set certificate verify locations:
> *   CAfile: none
>    CApath: /etc/ssl/certs
> * SSLv3, TLS handshake, Client hello (1):

The protocol version is decided here. By the server - based partially on 
what framing syntax that ClientHello used, and partially on what the 
client indicates it can support.

If the protocol itself could not be agreed to the server would terminate 
and I'd expect curl to either show an alert received now, or complain 
about early closure.


> * SSLv3, TLS alert, Server hello (2):

Here curl is receiving the ServerHello - which contains the cert and the 
servers chosen cyphers etc.


> * error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure > * Closing connection #0

So, curl is aborting willingly when processing that cert etc.

That "error:" line is produced by OpenSSL, not curl.

It might also abort due to cipher or extension issues, but IIRC the 
messages OpenSSL prints there explicitly contain the words cipher or 
extension respectively.


> 
> 2) You mentioned "leaving port 443 for encrypted connections", can you 
> please elaborate on why it might be problematic to use "http_port" 
> directive - i.e. have both plain-text and SSL connections?
> 

Because of problems like the one you are clearly showing by the way you 
worded that question. As if you think SSL connections are arriving at 
that port.

  ... it *does not* accept SSL connections.

The octet values for TLS and plain-text messages are incompatible. They 
can be interpreted by either one - with various results which are 
different to how they are supposed to be handled, and usually not nice 
results.


The "http_" part of the directive name indicates what protocol the 
parser attached to that port accepts. In this case plain-text HTTP. 
There are a few other protocols that can arrive there but they do so by 
using the plain-text HTTP syntax.


To receive port 443 traffic use the https_port. The "https_" part of 
that directive name means the bytes arriving to that port get shuffled 
through a TLS parser (eg OpenSSL) before going to the HTTP parser.

If you were thinking that ssl-bump option on the port made it accept 
SSL/TLS connections you would be wrong. SSL-Bump on an http_port is 
about applying a TLS parser *after* the HTTP parser - and only for the 
payload of plain-text HTTP CONNECT messages.


Other plain-text protocols which Squid supports that don't use the 
message HTTP-syntax have to use different port directives. For example; 
ftp_port directive for native FTP protocol.

Amos