En este punto, la terminología empieza a ser un poco confusa. Como ya lo he dicho, muchas otras guías consiguen lo mismo en Debian Jessie usando Squid 3.4 (
1,
2); CentOS 7 (
1 la cual a su modo es muy completa) y CentOS 6 (
1) entre otros.
Fue esta guía
(Squid (v3.5+) proxy with SSL Bump la que señala la forma correcta de configurar
ssl_bump en squid v3.5+; básandome en ella, hago una mejora mínima con la cuestión del certificado.
Crear un certificado puede ser algo tan sencillo como se recoge en
Intercept HTTPS CONNECT messages with SSL-Bump, pero ese procedimiento tiene el inconveniente de enviar al cliente la clave pública y privada con la que funciona el servidor. La separamos creando primero la clave privada de la siguiente forma:
$ openssl genrsa -out myCA.key 4096 [0/1508]
Generating RSA private key, 4096 bit long modulus
..........++
.....................................................................++
e is 65537 (0x010001)
Y luego la clave pública así:
$ openssl req -sha256 -new -x509 -days 1826 -key myCA.key -out myCA.crt
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:SV
State or Province Name (full name) [Some-State]:San Salvador
Locality Name (eg, city) []:San Salvador
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Dirección Central
Organizational Unit Name (eg, section) []:Establecimiento
Common Name (e.g. server FQDN or YOUR name) []:Establecimiento dependiente
Email Address []:vtacius@gmail.com
Cambiamos un poco el esquema de seguridad para los ficheros de la siguiente forma. Incluso las podría haber mejores
$ usermod -G ssl-cert proxy
$ chmod 770 /etc/ssl/private/
$ chmod 640 myCA.*
$ chown root:proxy myCA.*
$ cp -a myCA.key /etc/ssl/private/
$ cp -a myCA.crt /etc/ssl/certs/
Ahora configuramos precisamente a squid. No se necesita más que asegur tener las siguientes líneas:
http_port 10.168.4.1:3128
http_port 10.168.4.1:3129 transparent
https_port 10.168.4.1:3130 ssl-bump intercept generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/ssl/certs/myCA.crt key=/etc/ssl/private/myCA.key
...
ssl_bump stare all
ssl_bump splice all
...
La configuración de
ssl_bump aún sigue siendo un poco complicada, aún cuando existe
bastante documentación al respecto, hasta ahora entiendo que va de esta forma:
- ssl_bump stare all: Básicamente, permite una primera conexión con el servidor remoto. Por este paso es que se requiere que los clientes que usen proxy transparente tenga bien configurado la resolución DNS. Y no, no encuentro una mejor forma de cambiar este paso, si no se especifica, pues que la conexión no realiza bien.
- ssl_bumps splice all: En esta parte hacemos precisamente la conexión. Usar splice en lugar de bump permite al tráfico salir con menos trabajo por parte del servidor. En este punto, ni siquiera entiendo para iría a necesitar tanto trabajo por parte del proxy
En las guías anteriores, se recomiendan configuraciones como
ssl_bump server first all
sslproxy_cert_error deny all
sslproxy_flags DONT_VERIFY_PEER
Pero ninguna de estas deberían ser necesarias para esta versión de squid.
La otra opción que valdría la pena configurar es:
sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/squid_ssl/ -M 4MB
Ya que los valores por defecto no están del todo bien:
sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s /var/lib/ssl_db -M 4MB
En ambos casos, es necesario inicializar el directorio mencionado:
/usr/lib/squid/ssl_crtd -c -s /var/lib/squid_ssl/
Initialization SSL db...
Done
TODO: Pueden hacerse bastante mejoras aún con el certificado
