Solved: Unable to download files over HTTPS due to TLS encrypted alert

inflamer · Jun 6, 2017, 2:25 AM

I have an interesting issue with one of my pfSense instances (Running 2.3.3-RELEASE-p1), in that the firewall is unable to download bogon definition files for IPv4 and IPv6 - the system log outputs the following:


Jun 5 17:07:24	root		Could not extract fullbogons-ipv6.txt
Jun 5 17:07:24	root		Could not download https://files.pfsense.org/lists/fullbogons-ipv6.txt
Jun 5 17:05:39	root		Could not extract fullbogons-ipv4.txt
Jun 5 17:05:39	root		Could not download https://files.pfsense.org/lists/fullbogons-ipv4.txt
Jun 5 17:03:54	root		rc.update_bogons.sh is beginning the update cycle.

Having looked at rc.update_bogons.sh, I am trying to do a similar (yet simplified) manual download of the same files from a shell:


[2.3.3-RELEASE][admin@xyz.com]/tmp: /usr/bin/fetch -v -o fullbogons-ipv4.txt https://files.pfsense.org/lists/fullbogons-ipv4.txt
looking up files.pfsense.org
connecting to files.pfsense.org:443

At this point the command will hang like this for quite a while (over a minute), until proceeding with the following:


[2.3.3-RELEASE][admin@xyz.com]/tmp: /usr/bin/fetch -v -o fullbogons-ipv4.txt https://files.pfsense.org/lists/fullbogons-ipv4.txt
looking up files.pfsense.org
connecting to files.pfsense.org:443
SSL options: 83004bff
Peer verification enabled
Using CA cert file: /usr/local/etc/ssl/cert.pem
Verify hostname
TLSv1.2 connection established using ECDHE-RSA-AES256-GCM-SHA384
Certificate subject: /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.pfsense.org
Certificate issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
requesting https://files.pfsense.org/lists/fullbogons-ipv4.txt
fetch: transfer timed out
fetch: fullbogons-ipv4.txt appears to be truncated: 0/60268 bytes

I can successfully resolve files.pfsense.org from the pfSense instance - I have also checked, using openssl, that the certificate on files.pfsense.org verifies fine via /usr/local/etc/ssl/cert.pem. I also have a similar pfSense instance in which the same fetch command works just fine:


[2.3.3-RELEASE][admin@abc.com]/tmp: /usr/bin/fetch -v -o fullbogons-ipv4.txt https://files.pfsense.org/lists/fullbogons-ipv4.txt
looking up files.pfsense.org
connecting to files.pfsense.org:443
SSL options: 83004bff
Peer verification enabled
Using CA cert file: /usr/local/etc/ssl/cert.pem
Verify hostname
TLSv1.2 connection established using ECDHE-RSA-AES256-GCM-SHA384
Certificate subject: /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.pfsense.org
Certificate issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
requesting https://files.pfsense.org/lists/fullbogons-ipv4.txt
local size / mtime: 60268 / 1496638861
remote size / mtime: 60268 / 1496638861
fullbogons-ipv4.txt                           100% of   58 kB 5776 kBps 00m00s

Taking a packet capture while trying to download the bogons file via fetch, I see what appears to be a successful TLS handshake between pfSense and 162.208.119.41 (one of the two servers for files.pfsense.org), followed by around 20 1514-byte packets being received and acknowledged, followed by pfSense sending a TLSv1.2 encrypted alert ("Alert (21)") towards the far end followed by pfSense sending a RST.

As far as I understand, an encrypted alert of type 21 means that the data could not be decoded - could this mean I have some dodgy memory in my server, or could this be something else? This pfSense instance is running on VMware ESXi 6 on top of a Dell PowerEdge R630, in case that is relevant.

I am not seeing any other odd behavior on this pfSense except for the problem mentioned above.

Any input or suggestions appreciated.

Edit: It seems that the issue is more generic than being unable to download the bogons files - I seem to be having issues downloading other, unrelated files via HTTPS using fetch as well.

Edit 2: The problem turns out to be that IPv6 was configured on WAN with no apparent connectivity. Enabling System > Advanced > Networking > Prefer to use IPv4 even if IPv6 is available appears to have resolved the issue (Since files.pfsense.org was available both via v4 and v6. It is however strange that this is the cause and fix since an IPv4 HTTPS connection was made and was to some extent working until it failed.

inflamer · Jun 5, 2017, 9:33 PM

In case it is relevant,

Disable hardware checksum offload
Disable hardware TCP segmentation offload
Disable hardware large receive offload

are all ticked in System > Advanced > Networking.