POODLE implications?

Guest

What are the potential consequences of POODLE (via OpenSSL whatever) for pfSense 2.1.5? Is there a 2.1.6 under preparation?

Many thanks in advance

chemlud

kejianshi

OpenVPN uses TLSv1.0, or (with >=2.3.3) optionally TLSv1.2 and is thus not impacted by POODLE.

Is this OpenSSL/GnuTLS/browser specific?
No. It's a protocol (design) bug, not an implementation bug. This means you can't really patch it (unless you're changing the design of the old SSLv3).

Is it relevant for HTTPS only or also for IMAP/SMTP/OpenVPN and other protocols with SSL support?
The current attack vector as shown by the researchers works with controlling the plaintext sent to the server using Javascript being run on the victim's machine. This vector does not apply to non-HTTPS scenarios without using a browser.

Also, normally an SSL client doesn't allow the session to be downgraded to SSLv3 (having TLSv1+ seen in the handshake capabilities), but browsers want to be very backward compatible and the do. The combination with controlling plaintext and the specific way a HTTP header is built up makes it exploitable.

Conclusion: disable SSLv3 for HTTPS now, disable SSLv3 for other services in your next service window.

I'm an expert (at plagerizing posts to other threads.) Most of this came from ask ubuntu. Can't verify correctness myself, but seems to make sense.

Also, A current release of firefox is immune to this exploit already. Chrome and IE still seem to be vulnerable. ( https://www.poodletest.com )

Guest

Nope, the firefox released last night is still vulnerable, v34 as of 25-NOV will have SSL disabled by default.

enter about:config

find "tls"

change "security.tls.version.min" from 0 to 1

…and you are done. Same thing with Thunderbird (Settings -> Advanced -> General -> Edit Config), find TLS and change as described for Firefox... :-)

Hope that OpenVPN is safe... ;-)

jhochwald

Hi,

Here is a translated post from the german support Forum here:

The pfSense Webservices are vulnerable!

You might want to test it for yourself against your system:

openssl s_client -connect 192.168.1.1:8001 -ssl3
openssl s_client -connect 192.168.1.1:443 -ssl3

As a workaround (until there is a Patch, e.g. 2.1.6?) just Patch the following File:

/etc/inc/system.inc

Search for thew following Statement:

// Harden SSL a bit for PCI conformance testing
$lighty_config .= "ssl.use-sslv2 = \"disable\"\n";

Append the following:

$lighty_config .= "ssl.use-sslv3 = \"disable\"\n";

Just enable "Mitigate the BEAST SSL Attack" in the admin GUI. You will find this under System/Advanced in Admin Access

Here is the complete Patch that I applied to all my systems this afternoon (German Time):

[2.1.5-RELEASE][root@hotspot.bewoelkt.net]/etc/inc(45): diff system.inc system.inc.old
1155d1154
< 		$lighty_config .= "ssl.use-sslv3 = \"disable\"\n";
1173,1178c1172
< 			$lighty_config .= "ssl.cipher-list = \"AES256+EECDH:AES256+EDH\"\n";
< 			$lighty_config .= "ssl.use-compression = \"disable\"\n";
< 			$lighty_config .= "setenv.add-response-header = (\n";
< 			$lighty_config .= "	\"Strict-Transport-Security\" => \"max-age=63072000; includeSubDomains\",\n";
< 			$lighty_config .= "	\"X-Frame-Options\" => \"DENY\"\n";
< 			$lighty_config .= ")\n";
---
> 			$lighty_config .= "ssl.cipher-list = \"ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM\"\n";

P.S.: If you use other servers (e.g. Apache, nginx or postfix) you need to patch them as well. Just use any search engine ;-)

jimp

I committed a change earlier today to make lighty disable sslv3 - it can be added to an existing system using the system patches package.

For 2.2:
https://github.com/pfsense/pfsense/commit/5ff7f58e5903cca4f99edd20f9db402163527fd6
(Or update to a new snapshot)

For 2.1.x:
https://github.com/pfsense/pfsense/commit/29be59ad8ed25830f4e50a89977aca53ad8a29f4

Once the patch has been applied, restart the GUI from the console/ssh, reboot, or use /restart_httpd.php

sslscan makes a great test tool as well.

Before patch:

$ sslscan --ssl3 192.168.1.4 | grep -i Accepted
    Accepted  SSLv3  256 bits  DHE-RSA-CAMELLIA256-SHA
    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  256 bits  CAMELLIA256-SHA
    Accepted  SSLv3  128 bits  DHE-RSA-AES128-SHA
    Accepted  SSLv3  128 bits  DHE-RSA-CAMELLIA128-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  SSLv3  128 bits  CAMELLIA128-SHA
    Accepted  SSLv3  128 bits  RC4-SHA
    Accepted  SSLv3  128 bits  RC4-MD5
$

After patch:

$ sslscan --ssl3 192.168.1.4 | grep -i Accepted
$

Other potential concerns:
Reverse proxy packages like HAproxy or Apache+mod_security - They have options or allow advanced options to enable/disable SSLv3 - be sure to disable it there in your configuration.

PiBa

For those wondering about how to mitigate this with haproxy-devel package. (the other haproxy packages don't support ssl..)

When using 'SSL offloading' you can configure on all the frontends that use ssl in the 'Advanced ssl options' the textual option "no-sslv3" can be set this will disable SSLv3 for that frontend.

Dessertine

So PiBa you're saying it doesn't work with Squid as a reverse proxy ?

I tried to change lighttp conf, but still doesn't work.

I have 15 websites behind pfsense, what should I do? change to haproxy-devel package ?

Thx

jimp

It depends on what is handling the SSL.

If you have squid handling the SSL, you'll need to find a configuration change for it that will disable SSLv3.

If squid is passing the SSL through to the actual web server, then you'll need to disable SSLv3 there.

Dessertine

All server bellow are Ok with their configuration, test OK.

I assume that squid is handling the SSL, but I don't know how to disable it. think in "Squid Reverse HTTPS Settings" ?

Enable HTTPS reverse proxy is checked on my conf, but if I disable it, i can't access my website.

firewalluser

Dont know if this is useful?

http://www.squid-cache.org/Doc/config/http_port/

"TLS / SSL Options:

cert= Path to SSL certificate (PEM format).

key= Path to SSL private key file (PEM format)
if not specified, the certificate file is
assumed to be a combined certificate and
key file.

version= The version of SSL/TLS supported
1 automatic (default)
2 SSLv2 only
3 SSLv3 only
4 TLSv1.0 only
5 TLSv1.1 only
6 TLSv1.2 only

cipher= Colon separated list of supported ciphers.
NOTE: some ciphers such as EDH ciphers depend on
additional settings. If those settings are
omitted the ciphers may be silently ignored
by the OpenSSL library.

options= Various SSL implementation options. The most important
being:
NO_SSLv2 Disallow the use of SSLv2
NO_SSLv3 Disallow the use of SSLv3
NO_TLSv1 Disallow the use of TLSv1.0
NO_TLSv1_1 Disallow the use of TLSv1.1
NO_TLSv1_2 Disallow the use of TLSv1.2
SINGLE_DH_USE Always create a new key when using
temporary/ephemeral DH key exchanges
ALL Enable various bug workarounds
suggested as "harmless" by OpenSSL
Be warned that this reduces SSL/TLS
strength to some attacks.
See OpenSSL SSL_CTX_set_options documentation for a
complete list of options.

clientca= File containing the list of CAs to use when
requesting a client certificate.

cafile= File containing additional CA certificates to
use when verifying client certificates. If unset
clientca will be used.

capath= Directory containing additional CA certificates
and CRL lists to use when verifying client certificates.

crlfile= File of additional CRL lists to use when verifying
the client certificate, in addition to CRLs stored in
the capath. Implies VERIFY_CRL flag below.

dhparams= File containing DH parameters for temporary/ephemeral
DH key exchanges. See OpenSSL documentation for details
on how to create this file.
WARNING: EDH ciphers will be silently disabled if this
option is not set.

sslflags= Various flags modifying the use of SSL:
DELAYED_AUTH
Don't request client certificates
immediately, but wait until acl processing
requires a certificate (not yet implemented).
NO_DEFAULT_CA
Don't use the default CA lists built in
to OpenSSL.
NO_SESSION_REUSE
Don't allow for session reuse. Each connection
will result in a new SSL session.
VERIFY_CRL
Verify CRL lists when accepting client
certificates.
VERIFY_CRL_ALL
Verify CRL lists for all certificates in the
client certificate chain.

sslcontext= SSL session ID context identifier.
"

Dessertine

I don't think.
squid conf in pfsense is managed by pfsense, and like this :

# This file is automatically generated by pfSense
# Do not edit manually !
http_port xx.xx.xx.xx:3128
icp_port 7
dns_v4_first off
pid_filename /var/run/squid.pid
cache_effective_user proxy
cache_effective_group proxy
error_default_language en
icon_directory /usr/pbi/squid-i386/etc/squid/icons
visible_hostname localhost
cache_mgr admin@localhost
access_log /dev/null
cache_log /var/squid/logs/cache.log
cache_store_log none
sslcrtd_children 0
logfile_rotate 0
shutdown_lifetime 3 seconds
uri_whitespace strip

acl dynamic urlpath_regex cgi-bin \?
cache deny dynamic
cache_mem 8 MB
maximum_object_size_in_memory 32 KB
memory_replacement_policy heap LFUDA
cache_replacement_policy heap LFUDA
cache_dir ufs /var/squid/cache 100 32 256
minimum_object_size 0 KB
maximum_object_size 32 KB
offline_mode offcache_swap_low 90
cache_swap_high 95

# No redirector configured

#Remote proxies

# Setup some default acls
acl allsrc src all
acl localhost src 127.0.0.1/32
acl safeports port 21 70 80 210 280 443 488 563 591 631 777 901  3128 1025-65535
acl sslports port 443 563
acl manager proto cache_object
acl purge method PURGE
acl connect method CONNECT

# Define protocols used for redirects
acl HTTP proto HTTP
acl HTTPS proto HTTPS

http_access allow manager localhost

http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !safeports
http_access deny CONNECT !sslports

# Always allow localhost connections
http_access allow localhost

request_body_max_size 0 KB
delay_pools 1
delay_class 1 2
delay_parameters 1 -1/-1 -1/-1
delay_initial_bucket_level 100
delay_access 1 allow allsrc

# Reverse Proxy settings
http_port xx.xx.xx.xx:80 accel defaultsite=xxx.xxx.com vhost
https_port  xx.xx.xx.xx:443 accel cert=/usr/pbi/squid-i386/etc/squid/53a2b80f5b90d.crt key=/usr/pbi/squid-i386/etc/squid/53a2b80f5b90d.key defaultsite=xxx.xxx.com vhost
#
cache_peer  xx.xx.xx.xx.2 parent 443 0 proxy-only no-query no-digest originserver login=PASS round-robin ssl sslflags=DONT_VERIFY_PEER front-end-https=auto name=rvp_IPB-CAS

acl rules...

I'm not sure I can put "options" in this file.

And I think is there a way to configure squid squid pass through ssl, on pfsense.

Cino

Squid itself has the options but the pfSense GUI doesn't. You can could reach out to developer and see if he can add them into the GUI.

http://www.squid-cache.org/Doc/config/cache_peer/

For me, I use squid as a proxy (to block ads, certain sites for the kids, logging) but then I fire-up another instance of squid (script on startup) to use my own config file for reverse-proxy. It allows me to have more control since not all the options are in the GUI and also allows me to have 2 separate log files.

Dessertine

I only use pfenses as a reverse proxy in my DMZ, to unload my firewall witch manage all outbound traffic. So maybe I can just instantiate squid with a script too.

How do you do?

On a onother side, I asked developer how to do with the GUI.

nss

So, did someone find a way to tell squid3 to not use SSLv3 for reverse proxy?

I tried to set this line, under "Service", "Proxy Server", in the "Custom Options" field:

sslproxy_options NO_SSLv2,NO_SSLv3

but it seems I still have ssl3 enabled

cdburgess75

anyone?

default666

http://www.sigma.zone/2015/03/securing-ssl-cipher-suite-in-pfsense.html

looks like working one

qualys gives grade B

it's for squid 3 Reverse Proxy