Squid 3.5.10 FATAL: Received Segment Violation...dying?

Question

FreeBSD

I'm testing in VirtualBox FreeBSD 10.2 + Squid 3.5.10. Transparent proxy with https filtering without certificate spoofing. The port is compiled with support for ssl, sslcrtd, ipfw. Squid.conf spied in this guide habrahabr.ru/post/267851/.
The problem is that squid crashes whenever the client tries to send anything to port 443. Here is the cache.log:
2015/10/08 15:17:21.145 kid1| SECURITY ALERT: Host header forgery detected on local=74.125.143.100:443 remote=192.168.10.6:43373 FD 10 flags=33 (local IP does not match any domain IP)
FATAL: Received Segment Violation...dying.
After a header substitution error, it immediately crashes. I couldn't google this problem so I'm writing here. Maybe someone had this? Thanks in advance for your replies.

squid.conf:
acl localnet src 192.168.10.0/24 # RFC1918 possible internal network
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
dns_nameservers 8.8.8.8
http_access deny ! Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet
http_access allow localhost
http_access deny all
http_port 127.0.0.1:3128 intercept options=NO_SSLv3:NO_SSLv2
https_port 127.0.0.1:3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/usr /local/etc/squid/squidCA.pem
always_direct allow all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
acl blocked ssl::server_name "/etc/squid/blocked_https.txt"
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump terminate blocked
ssl_bump splice_programd
all /lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB
cache deny all

ipfw.rules:
#!/bin/sh
cmd="/sbin/ipfw -q"
oif="em0"
oip="10.0.2.15" iif
="em1"
iip="192.168.10.5"
mylan="192.168.10.0 /24"
${cmd} -f flush
${cmd} add 1038 allow ip from any to any via lo0
${cmd} add 1039 allow tcp from me to any out via ${oif} keep-state uid squid
${cmd } add 1040 fwd 127.0.0.1,3128 tcp from ${mylan} to any 80 out via ${oif}
${cmd} add 1041 fwd 127.0.0.1,3129 tcp from ${mylan} to any 443 out via ${oif }
${cmd} add 1042 allow ip from any to any via ${iif}
${cmd} nat 1 config if ${oif} reset same_ports deny_in
${cmd} add 1043 nat 1 ip from any to any via ${oif }

Answer 1

Host header forgery means that a request has arrived from the client to an
IP that does not have the domain that appears in the "Host" field of the
HTTP request. Squid resolves the domain name from the host field and checks the list
of received IPs for the presence of the IP that the client is trying to break into.
If there is no such IP in the list, then the squid rejects such a request. But
there is a bug in the handler of this tops:
bugs.squid-cache.org/show_bug.cgi?id=4099
There is no fix for this bug yet, there are a couple of crutches that help reduce
the likelihood of protection from the host header forgery.

Answer 2

In general, the problem seems to have not been solved, but for myself I solved everything by switching to using an opaque proxy. Everything is perfectly proxied there, incl. https. The only negative is that you need to configure the browser on the client. Thanks to the respected athacker for the advice.

Answer 3

Install version 3.5.8, the article says that in versions higher than 3.5.8 there are bugs that either put your https on the shoulder blades, or the squid crashes. With version 3.5.8, using libressl with a patch, everything works fine. People with OS Debian 8, Centos, FreeBSD, Gentoo, Ubuntu unsubscribed.