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@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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
