23 Ott 18 How to disable Diffie-Hellman ciphers on apache

If you are getting errors like “DH key too small” you can avoid using DH ciphersuites on apache.
You can obtain that using Perfect forward secrecy, or disabling all DH ciphersuites like this:

SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW

Tags: apache, cipher, debian, http, https, Linux, openssl, server, sysadmin
Filed in Linux OS, Open source, Sysadmin pills with 0 Comments

16 Apr 16 How to check if JCE Unlimited Strength policy is installed

JCE Unlimited Strength policy files are two files distributed by Oracle (this is for jdk8: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html) that must be installed inside your JDK/jre/lib/security path if you want to unlock high strength cryptographic security for you java environment.

You need it for sure in a server environment outside USA.

If you don’t have this stuff installed, your jboss, tomcat, or any other server or client with a keylength higher than 1024 will not work.
To enable JCE Unlimited Strength you simply need to unzip the file downloaded from Oracle and copy US_export_policy.jar and local_policy.jar files in <JDK>/jre/lib/security.

You can check if JCE is unlimited using this command:

jrunscript -e ‘exit (javax.crypto.Cipher.getMaxAllowedKeyLength(“RC5”) >= 256);’; if [ $? -eq 1 ]; then echo “JCE Unlimited OK”; else echo “JCE NOT Unlimited”; fi

The jrunsctipt command is installed inside your JDK/bin path.

Tags: authority, cipher, https, java, jce, library, Linux, policy, server, sysadmin
Filed in Linux OS, Sysadmin pills with 0 Comments

21 Feb 14 HOWTO generate a SAN (Subject Alternative Names) SSL CSR with OpenSSL

There is a cool SSLv3 protocol extension that’s called SAN (Subject Alternative Names). With this extension you can create a single SSL X509 certificate that is valid for several domain names, instead of a classic certificate that’s valid for one domain name only.

You can ofcourse create this kind of certificate with OpenSSL. We are now going to see how to do that.
Fist you have to create a file called openssl.cnf and put it for example into a temporary dir. The file should begin with:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

This is to enable SSLv3 req extensions.
Now, you have to add your custom informations to the openssl.cnf file: those informations will be reflected on the next steps.
Add something like this to openssl.cnf:

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = IT
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Italy
localityName = Locality Name (eg, city)
localityName_default = Rome
organizationName = Organization name
organizationName_default = My company name Srl
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = System Techies
commonName = Common Name (eg, YOUR name)
commonName_max = 64
#commonName_default = www.myfirstdomain.it
emailAddress = Email Address
emailAddress_max = 40

The informations above are used by the “openssl req” command to ask you data to generate your certificate request.
Then, add this block of informations into the openssl.cnf file:

[v3_req]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @alt_names

Those informations will enable some extra useful things on your certificate request that will hopefully became valid on your brand new SSLv3 certificate. For example you are requesting your Certification Authority to release a X509 SSLv3 certificate with server and client authentication purposes, plus other certificate goodies.

Now the cool part: this is where you are asking your CA to release a certificate with Alternative Names (certificate valid for several domains). Append this stuff in openssl.cnf:

[alt_names]
DNS.1   = www.myfirstdomain.it
DNS.2   = myfirstdomain.it
DNS.3   = www.myalternativedomain.it
# you could also specify IP addresses like this:
# IP.1 = 1.2.3.4

OK. You are almost ready to create your CSR, but first you have to generate your private key.
NOTE that many CA are now requesting a private key of 2048 bits or more. Warned: a key of 1024 bits is not recommended!
To generate a 2048 bits private key, as usual, execute this command:

openssl genrsa -out server.key 2048

Perfect. It’s time to create the Certificate Request (PKCS#10) with SSLv3 extensions:

openssl req -new -out server.csr -key server.key -config openssl.cnf

Now, send your new server.csr file to your Certification Authority that will hopefully accept the request and relase a valid X509 SSLv3 certificate with SAN.

Good luck and enjoy.

Tags: apache, authority, ca, cipher, dns, http, https, Linux, openssl, san, server, sysadmin
Filed in Linux OS, Open source, Sysadmin pills with 1 Comment

13 Nov 13 Apache HTTPD as 2WAY (mutual) authentication SSL reverse proxy balancer

In this small article I’ll instruct myself (and you too?) how to create a 2 way authentication (mutual authentication) SSL reverse proxy balancer gateway. This configuration is useful in any enterprise environment where it’s requested to separate clients, the frontend and the backend, and when the traffic between clients and the gateway, and between the gateway and the backends must be encrypted.
This also ensure the clients and the backends to be authentic, and avoids Man In The Middle attacks.

Since the reverse proxy is in the middle between the clients and the backends, it’s requested for the clients to send a known client certificate to the gateway (apache), so that the gateway can recognize them. This is done with X509 certificates.
For the same reason, each backend contacted by the gateway is requested to respond with a valid and known server certificate. This is also done with X509 certificates.
Generally, the clients and the backends will also check their peer’s (apache) certificate to be known and valid, so that if someone is going to impersonate the gateway, it will be found and will not be considered authentic.

To do so, we’ll use:

apache httpd
mod_ssl
mod_proxy_balancer + mod_proxy + mod_proxy_http

Everything is done with a simple and single virtualhost in apache to be included in httpd.conf.
A working example is given below (assumes apache to be installed in /opt/apache, working with IP 11.22.33.44 on port 443):

<VirtualHost 11.22.33.44:443>
# General setup for the virtual host
DocumentRoot “/opt/apache/htdocs”
ServerName 11.22.33.44:443
ServerAdmin hostmaster@yoursite.com
CustomLog “|/opt/apache/bin/rotatelogs /opt/apache/logs/ssl_request_%Y%m%d.log 43200” “%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b”
ErrorLog “|/opt/apache/bin/rotatelogs /opt/apache/logs/error_%Y%m%d.log 43200”
CustomLog “|/opt/apache/bin/rotatelogs /opt/apache/logs/access_%Y%m%d.log 43200” combined

# SSL CONFIGURATION – SERVER SIDE
# Enable SSL Server on this virtualhost
SSLEngine on
# Disable SSLv2 in favor of the more robust and secure SSLv3
SSLProtocol all -SSLv2
# List of supported cryptografic server cipher suites
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5

# Apache server certificate
SSLCertificateFile “/opt/apache/conf/ssl/server.pem”
# Apache server private key
SSLCertificateKeyFile “/opt/apache/conf/ssl/key.pem”
# Apache server CA certificate (certificate of who released your server certificate)
SSLCertificateChainFile “/opt/apache/conf/ssl/ca.pem”
# Client’s CA certificates (list of certificates of who released your client’s certificates)
SSLCACertificateFile “/opt/apache/conf/ssl/ca.pem”
# It’s mandatory for apache to authenticate the client’s certificate
SSLVerifyClient require
# END OF SSL CONFIGURATION – SERVER SIDE

# SSL CONFIGURATION – CLIENT SIDE
# Enable SSL Client on this virtualhost (the traffic to the backends can be encrypted)
SSLProxyEngine on
# Apache client CA certificate (certificate of who released your client certificate)
SSLProxyMachineCertificateChainFile “/opt/apache/conf/ssl/ca.pem”
# Apache client private key + client certificate (concatenated in a single file)
SSLProxyMachineCertificateFile “/opt/apache/conf/ssl/client.pem”
# Backends’ CA certificates (list of certificates of who released your backends’ certificates)
SSLProxyCACertificateFile “/opt/apache/conf/ssl/ca.pem”
# It’s mandatory for apache to authenticate the backends’ certificate
SSLProxyVerify require
# END OF SSL CONFIGURATION – CLIENT SIDE

<FilesMatch “\.(cgi|shtml|phtml|php)$”>
SSLOptions +StdEnvVars
</FilesMatch>
<Directory “/opt/apache/cgi-bin”>
SSLOptions +StdEnvVars
</Directory>

BrowserMatch “MSIE [2-5]” \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

# Define a load balancer worker to be used to balance the HTTPS traffic to three backends.
# The traffic between apache and the backends is encrypted
<Proxy balancer://httpslb>
# Define the first backend (https) with 2 way auth
BalancerMember https://192.168.1.11:443/ route=worker1 retry=10
# Define the second backend (https) with 2 way auth
BalancerMember https://192.168.1.12:443/ route=worker2 retry=10
# Define the third backend (https) with 2 way auth
BalancerMember https://192.168.1.13:443/ route=worker3 retry=10
</Proxy>

# Don’t send the “/balancer-manager” uri to the backends
ProxyPass /balancer-manager !
# Distribute the traffic (any url, since it is “/”) to the backends with round robin + cookie based session persistence
ProxyPass / balancer://httpslb/ lbmethod=byrequests stickysession=JSESSIONID

</VirtualHost>

If the clients and the backends are configured to check the gateway (apache) certificates, this is considered to be a very secure configuration.

Enjoy!

Tags: apache, ca, cipher, cookie, debian, http, https, Linux, openssl, proxy, reverse, server, sysadmin
Filed in General, Linux OS, Open source, Sysadmin pills with 3 Comments

01 Giu 11 Openssl e ciphers… questi sconosciuti

La suite openssl supporta differenti meccanismi di crittografia asimmetrica.
Il client e il server negoziano in fase di handshake la modalita’ di cifratura che utilizzeranno per il trasferimento sicuro dei dati.

In openssl le ciphers implementano 4 algoritmi:
1) Key Exchange Algorithm (scambio delle chiavi)
Sono RSA o Diffie-Hellman

2) Authentication Algorithm (autenticazione dei sistemi)
RSA, Diffie-Hellman, DSS o nessuno

3) Cipher/Encryption Algorithm (cifratura dello stream di dati)
DES, Triple-DES, RC4, RC2, IDEA o nessuno

4) MAC Digest Algorithm (verifica della validita’ del pacchetto)
MD5, SHA o SHA1

Il comando “openssl s_client -ciphers <parametro cipher>” permette di forzare il client (in questo caso il comando openssl stesso) ad utilizzare i meccanismi di cifratura piu’ deboli (parametro LOW), medi (MEDIUM) o piu’ sicuri (HIGH). Tuttavia per poter colloquiare in modo corretto, anche il server SSL deve supportare tali modalita’.

La suite openssl presente al momento sul mio pc (0.9.8k) implementa le seguenti ciphers:

LOW (tutti hanno chiave di cifratura inferiore a 128 bit, e firma hash SHA1 o MD5):
ADH-DES-CBC-SHA         SSLv3 Kx=DH       Au=None Enc=DES(56)   Mac=SHA1
EDH-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA Enc=DES(56)   Mac=SHA1
EDH-DSS-DES-CBC-SHA     SSLv3 Kx=DH       Au=DSS Enc=DES(56)   Mac=SHA1
DES-CBC-SHA             SSLv3 Kx=RSA      Au=RSA Enc=DES(56)   Mac=SHA1
DES-CBC-MD5             SSLv2 Kx=RSA      Au=RSA Enc=DES(56)   Mac=MD5

MEDIUM (tutti hanno chiave di cifratura uguale a 128 bit, e firma hash SHA1 o MD5):
ADH-RC4-MD5             SSLv3 Kx=DH       Au=None Enc=RC4(128) Mac=MD5
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA Enc=RC4(128) Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA Enc=RC4(128) Mac=MD5
RC2-CBC-MD5             SSLv2 Kx=RSA      Au=RSA Enc=RC2(128) Mac=MD5
RC4-MD5                 SSLv2 Kx=RSA      Au=RSA Enc=RC4(128) Mac=MD5

HIGH (tutti hanno chiave di cifratura superiore o uguale a 128 bit, e firma hash SHA1 o MD5):
ADH-AES256-SHA          SSLv3 Kx=DH       Au=None Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS Enc=AES(256) Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA Enc=AES(256) Mac=SHA1
ADH-AES128-SHA          SSLv3 Kx=DH       Au=None Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS Enc=AES(128) Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA Enc=AES(128) Mac=SHA1
ADH-DES-CBC3-SHA        SSLv3 Kx=DH       Au=None Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA Enc=3DES(168) Mac=SHA1
DES-CBC3-MD5            SSLv2 Kx=RSA      Au=RSA Enc=3DES(168) Mac=MD5

e altre modalita’ che non fanno capo ai tre alias descritti (LOW, MEDIUM e HIGH).

Per quanto riguarda la parte SERVER (per i bravi che usano APACHE) e’ possibile impostare le ciphers supportate tramite l’utilizzo del parametro SSLCipherSuite, ad esempio mettendo qualcosa del genere:
SSLCipherSuite +HIGH:+MEDIUM:!LOW:+SSLv2

Sempre parlando di apache, se non specificato, il default e’: SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
ovvero si cerca di mantenere la compatibilita’ con i client piu’ vecchi e che quindi supporano solo ciphers poco robuste.

Scusate la “lezione di crittografia” ma secondo me serve per fare un po’ di chiarezza generale sull’argomento, spesso un po’ oscuro a molti.

Ciao, Dino.