I am trying to install squid 3.5.4 (on docker, running debian 8) and run it in ssl-bump mode.
Compilation:
./configure --prefix=/opt/squid --srcdir=. --disable-maintainer-mode \
--disable-dependency-tracking --disable-silent-rules --enable-inline\
--disable-arch-native --enable-async-io=8 \
--enable-storeio=ufs,aufs,diskd,rock \
--enable-removal-policies=lru,heap --enable-delay-pools \
--enable-cache-digests --enable-icap-client \
--enable-follow-x-forwarded-for \
--enable-auth-basic=DB,fake,getpwnam,LDAP,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB \
--enable-auth-digest=file,LDAP \
--enable-auth-negotiate=kerberos,wrapper \
--enable-auth-ntlm=fake,smb_lm \
--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,unix_group,wbinfo_group \
--enable-url-rewrite-helpers=fake --enable-eui \
--enable-esi --enable-icmp --enable-zph-qos \
--disable-translation --with-filedescriptors=65536 \
--with-large-files --with-default-user=squid \
--enable-linux-netfilter \
CFLAGS="-g -O2 -fPIE -Wall" LDFLAGS="-fPIE -pie -Wl,-z,relro -Wl,-z,now" CPPFLAGS="-D_FORTIFY_SOURCE=2" \
CXXFLAGS="-g -O2 -fPIE " --enable-ssl --with-openssl --enable-ssl-crtd
Changed configuration (squid.conf) (rest is default):
# Squid normally listens to port 3128 \
http_port 9090
sslcrtd_program /opt/squid/libexec/ssl_crtd -s /opt/squid/var/lib/ssl_db -M 4MB
https_port 8080 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB key=/opt/squid/certs/private.pem cert=/opt/squid/certs/public.pem
### New configuration for Squid version 3.5
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all
### New config ends
sslproxy_capath /etc/ssl/certs
sslproxy_cert_error allow all
always_direct allow all
sslproxy_flags DONT_VERIFY_PEER
Generated certificates:
openssl req -new -newkey rsa:2048 -sha256 -days 365 -nodes -x509 -keyout private.pem -out public.pem
Generate squid certs dir and change ownership:
/opt/squid/libexec/ssl_crtd -c -s /opt/squid/var/lib/ssl_db -M 4MB
chown -R squid:squid /opt/squid/var/lib/ssl_db
CA Root certs are present in the default path
squid#525f5d9c759a:/opt/squid/certs$ ls -lsthr /etc/ssl/certs | wc -l
741
I am testing this configuration, using HTTP CONNECT, configuring the proxy directly in the browser.
ISSUE:
I get the following error when the browser request hits the proxy
8zjv9ksCWknblqfZ3rjWczvKNRboHpu940olZAbvSP0JWSXhFfRRTIsHIHD2/rt/
n5/qsURq/WLodLffFxuk+bLVTDZu
-----END PRIVATE KEY-----
2015/05/04 15:13:46.468 kid1| client_side.cc(3981) sslCrtdHandleReply: Certificate for 172.17.0.7 was successfully recieved from ssl_crtd
2015/05/04 15:13:46.468 kid1| client_side.cc(3664) httpsCreate: will negotate SSL on local=172.17.0.7:2222 remote=172.17.42.1:40686 FD 10 flags=33
2015/05/04 15:13:46.468 kid1| AsyncCall.cc(26) AsyncCall: The AsyncCall ConnStateData::requestTimeout constructed, this=0x7f0357a16c10 [call105]
2015/05/04 15:13:46.468 kid1| Error negotiating SSL connection on FD 10: Success (0)
2015/05/04 15:13:46.468 kid1| AsyncCall.cc(93) ScheduleCall: comm.cc(730) will call ConnStateData::connStateClosed(FD -1, data=0x7f03575d43b8) [call95]
2015/05/04 15:13:46.468 kid1| AsyncCallQueue.cc(55) fireNext: entering ConnStateData::connStateClosed(FD -1, data=0x7f03575d43b8)
2015/05/04 15:13:46.468 kid1| AsyncCall.cc(38) make: make call ConnStateData::connStateClosed [call95]
2015/05/05 10:00:25| pinger: Initialising ICMP pinger ...
2015/05/05 10:00:25| icmp_sock: (1) Operation not permitted
2015/05/05 10:00:25| pinger: Unable to start ICMP pinger.
2015/05/05 10:00:25| icmp_sock: (1) Operation not permitted
2015/05/05 10:00:25| pinger: Unable to start ICMPv6 pinger.
2015/05/05 10:00:25| FATAL: pinger: Unable to open any ICMP sockets.
Sending a curl request shows this:
curl --proxy https://localhost:8080 -w '\n' https://google.com -v
* Rebuilt URL to: https://google.com/
* Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.42.0
> Proxy-Connection: Keep-Alive
>
* Proxy CONNECT aborted
* Connection #0 to host localhost left intact
curl: (56) Proxy CONNECT aborted
Can anyone help with this?
Response got on Squid mailing lists:
http://squid-web-proxy-cache.1019090.n4.nabble.com/Error-negotiating-SSL-connection-on-FD-12-Success-td4671090.html
Summary: use http_port for handling the requests from browsers, which have proxy information directly specified.
Use https_port with ssl-bump and corresponding tag "intercept" or "tproxy" to use in transparent mode.
Related
I'm receiving the following SSL error on my rake rspec unit tests when I try to connect to the vault on my docker container using HTTPS:
OpenSSL::SSL::SSLError:
SSL_connect returned=1 errno=0 state=error: wrong version number
We're using docker to load a local instance of a hashicorp vault
Here's the command I run to generate the TLS Certificates
RUN openssl req -new -newkey rsa:4096 -x509 -sha256 -days 365 -nodes -subj "$SUBJ" -out /vault/certificates/tls/vault.crt \
-keyout /vault/certificates/tls/vault.key
When I log into the docker container and run openssl version I get:
/ # openssl version
OpenSSL 1.1.1k 25 Mar 2021
When I try to connect to the docker container from my local prompt, I get:
$ openssl s_client -connect 'localhost:8200'
CONNECTED(000001F0)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1620224762
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
26612:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:827:
When I run this command in my local irb I get:
irb(main):001:0> require 'openssl'
=> true
irb(main):002:0> OpenSSL::SSL::SSLContext::DEFAULT_PARAMS
=> {:min_version=>769, :verify_mode=>1, :verify_hostname=>true, :options=>2147614804}
irb(main):003:0>
This is my vault configurations:
listener "tcp" {
address = "[::]:8200"
cluster_address = "[::]:8201"
tls_cert_file = "/vault/certificates/tls/vault.crt"
tls_key_file = "/vault/certificates/tls/vault.key"
}
Also, i noticed in the docker logs we have two listeners now:
Listener 1: tcp (addr: "0.0.0.0:1234", cluster address: "0.0.0.0:1235", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
Listener 2: tcp (addr: "[::]:8200", cluster address: "[::]:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "enabled")
And my docker vault server startup command is:
vault server -config=/vault/config -dev-root-token-id=myroot -dev-listen-address=0.0.0.0:1234 -dev &
And i noticed in the logs its still seeing an http connection...
Error writing data to pki/root/generate/internal: Put https://127.0.0.1:1234/v1/pki/root/generate/internal: http: server gave HTTP response to HTTPS client
Error writing data to pki/config/urls: Put https://127.0.0.1:1234/v1/pki/config/urls: http: server gave HTTP response to HTTPS client
Error writing data to pki/roles/localhost: Put https://127.0.0.1:1234/v1/pki/roles/localhost: http: server gave HTTP response to HTTPS client
Error writing data to pki/issue/localhost: Put https://127.0.0.1:1234/v1/pki/issue/localhost: http: server gave HTTP response to HTTPS client
I'm kind of lost right now on how to handle this.
I'm trying to run MQTT broker (Mosquitto) with TLS support, I followed http://rockingdlabs.dunmire.org/exercises-experiments/ssl-client-certs-to-secure-mqtt to generate certificates and configuration. If I run
sudo /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf -d -v
It throws error in /var/log/mosquitto/mosquitto.log
mosquitto version 1.4.8 (build date Fri, 19 Feb 2016 12:03:16 +0100) starting
Config loaded from /etc/mosquitto/mosquitto.conf.
Opening ipv4 listen socket on port 8883.
Opening ipv6 listen socket on port 8883.
Error: Unable to load server key file "/etc/mosquitto/certs/mqtt_server.key". Check keyfile.
Here is my configuration in conf.d/mymqtt.conf
# MQTT over TLS/SSL
listener 8883
cafile /etc/mosquitto/ca_certificates/mqtt_ca.crt
certfile /etc/mosquitto/certs/mqtt_server.crt
keyfile /etc/mosquitto/certs/mqtt_server.key
require_certificate true
tls_version tlsv1.2
user mosquitto
And these certificate and key files are present in proper location
And here is the content of default mosquitto.conf
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
I ran into the same issue once and it was because the key was password protected. I changed the file settings so that the key file was readable only by a specific set of users and removed the password.
For posterity:
You get this error if the key doesn't match the certificate also. So remember to check that:
openssl rsa -noout -in -key.pem -modulus | openssl md5
should match
openssl x509 -noout -in cert.pem -modulus | openssl md5
I spent hours trying to fix this until I realised I'd mixed up the keys.
I am trying to access the docker remote rest api but I am not able to access it.
e.g.
$ curl -v https://192.168.99.100:2376/images/json
* About to connect() to 192.168.99.100 port 2376 (#0)
* Trying 192.168.99.100...
* Adding handle: conn: 0x7f8cd380fe00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f8cd380fe00) send_pipe: 1, recv_pipe: 0
* Connected to 192.168.99.100 (192.168.99.100) port 2376 (#0)
* SSL certificate problem: Invalid certificate chain
* Closing connection 0
curl: (60) SSL certificate problem: Invalid certificate chain
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
$ curl -v http://192.168.99.100:2376/images/json
* About to connect() to 192.168.99.100 port 2376 (#0)
* Trying 192.168.99.100...
* Adding handle: conn: 0x7f9411008c00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f9411008c00) send_pipe: 1, recv_pipe: 0
* Connected to 192.168.99.100 (192.168.99.100) port 2376 (#0)
> GET /images/json HTTP/1.1
> User-Agent: curl/7.30.0
> Host: 192.168.99.100:2376
> Accept: */*
>
* Connection #0 to host 192.168.99.100 left intact
but if I run the docker command it works:
$docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
subh007/docker_quagga v1 fd482b733697 6 months ago 263.5 MB
I have also tried to follow the suggestion from stack post., but it din't work for me, looks like it worked for boot2docker. Currently I am using the mac os X (10.9.4).
Following is docker machine details :
$ docker-machine env default
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/Users/subh/.docker/machine/machines/default"
export DOCKER_MACHINE_NAME="default"
# Run this command to configure your shell:
# eval "$(docker-machine env default)"
Please let me know if I am missing some understanding.
The new version of CURL uses Apple's secure transport API instead of OpenSSL API. Use the P12 format of certificates. Try this -
cd $DOCKER_CERT_PATH
openssl pkcs12 -export -inkey key.pem -in cert.pem -CAfile ca.pem -chain -name client-side -out cert.p12 -password pass:mypass
curl https://192.168.99.100:2376/images/json --cert $DOCKER_CERT_PATH/cert.p12 --pass mypass --key $DOCKER_CERT_PATH/key.pem --cacert $DOCKER_CERT_PATH/ca.pem
I have make a request to url from the same server with a cron task. In the past I did this with the next bash script:
#!/bin/sh
curl "http://www.mydomain.es/myfolder/importTwitter" >> /var/log/mydomain/import_twitter.log
I migrated the website to https and the curl command fails returning the next error:
* About to connect() to www.mydomain.es port 443 (#0)
* Trying xxx.xxx.xxx.xxx...
* Connection refused
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
I have tried to add the next parameters to the curl command, and get the same error:
--cacert -> specify ssl ca root certificate
--cert -> specify ssl pem certificate
--location -> using the http url and force to follow redirects
--insecure -> allows insecure curl connections
Finally I also have tried make the request from another host and works fine, but I have do the request from the same server.
The server have Debian 3.2.65-1+deb7u2 x86_64
Curl version:
curl 7.26.0 (x86_64-pc-linux-gnu) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
* Connection refused
You've got your problem right there. Long before anything with crypto can start, your server simply does not allow a connection from your host.
Make sure your server is configured correctly and that no firewall is blocking loopback connections to port 443.
I am trying to use cURL and get the following error on every https request I make. The error is always the same. HTTP requests work flawlessly. The verbose output is quite useless.
bash:$ curl https://google.com -vv
* Adding handle: conn: 0x7fe09b803a00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fe09b803a00) send_pipe: 1, recv_pipe: 0
* About to connect() to google.com port 443 (#0)
* Trying 74.125.226.129...
* Connected to google.com (74.125.226.129) port 443 (#0)
* Unknown SSL protocol error in connection to google.com:-9805
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to google.com:-9805
bash:$ curl https://google.com -V
curl 7.30.0 (x86_64-apple-darwin13.0) libcurl/7.30.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz
bash:$ openssl s_client -connect google.com:443 < /dev/null
CONNECTED(00000003)
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
24255:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-50/src/ssl/s23_lib.c:182:
The results are the same on two different networks, so it does not appear to be network-specific. Attempting to connect using openssl s_client fails similarly so it is not library-dependent either (curl on the Mac uses SecureTransport). The debug output of s_client shows that the SSL handshake proceeds normally to the point where the client sends ChangeCipherSpec and the Finished messages but does not receive ChangeCipherSpec back from the server.
I have tried running these commands on a Debian VM on my Mac, and everything there runs correctly. In addition, using curl to connect to a local OpenSSL server (openssl s_server with a self-signed certificate) also works correctly.
I have looked through other answers on this forum and other places on the internet, but haven't found an answer. Most people's issues involve particular servers and the configuration of SSL on these servers. Mine however is problematic anytime HTTPS is used (with any website).
It was suggested that the issue might be in the certificate store. But if I understand it correctly, if the issue was with the certificate store, it would cause certificates to be rejected by all apps. However, all my browsers (chrome, safari, firefox) negotiate SSL with no problems. There is nothing suspicious in the environment variables for GUI applications or the shell.
Can someone please suggest what I should be looking into to solve the problem? Can it be that something is not properly configured? What should I be looking for?