Improved squid3 reverse-proxy security

[geijt]

• Added strong ciphers
• Disabled SSLv2 and SSLv3 options
• Added SINGLE_DH_USE and CIPHER_SERVER_PREFERENCE options
• Added use of DHParam file

[btsimon97]

You might want to consider adding an ability to choose the cipher list, if the user needs to support older clients that aren't using latest encryption. Also, I would base the cipher list off of Mozilla's Cipher Lists (modern specifically), as those are updated to reflect current browser support and security. If you implement the selection ability, you could default to Mozilla's modern cipher list, and provide the option of switching to their intermediate list for backwards compatibility. The list (along with browser support and other notes) is available at: https://wiki.mozilla.org/Security/Server_Side_TLS

[btsimon97]

Also, you need to add some logic that checks to make sure the DHParams files exist when setting the cipher suite and DH flags, otherwise squid enters a mode that makes it completely useless when the file is not there (clients get a no cipher suite overlap message and connections fail). Further, on package install, there needs to be a facility to generate these files if they don't exist. Even though these files exist for base installs, you might want to consider having a separate DHParams file specifically for squid, so these files can be regenerated on-demand if needed, and you don't have to worry about what happens if the files move in a later release of pfsense.

[geijt]

I agree that some logic to validate the existance of the DHParams file and not setting a strong cipher suite if not found is useful. But about the DHParams and ciphers, my previous pull request was rejected because of an option to generate DHParams files and I needed to use settings like those used for the HTTPS proxy. so I start to get confused here and I'm not sure whats expected..

[btsimon97]

I checked the previous pull request, sorry I didn't see that before. I guess what you could do is check for a custom dhparams file in a specific directory and set that if it exists, otherwise default to the predefined dhparams files. Basically, gray out the GUI length options if a custom file is detected, and document the process for generating it.

The reason I suggested using the Mozilla ciphers is because they are well-documented and easily accessed, which makes a server admin's job easier when troubleshooting crypto errors. (speaking from experience here).

Basically if you used Mozilla's lists you'd have radio buttons to toggle b/w the modern (the most secure suite, but less backwards compatible) and intermediate (more compatible but less secure) cipher suites defined at Mozilla, and a link to the site to explain each.

Disabling SSL globally is a good practice, as it shouldn't be negotiated. However, Elliptic curve DH isn't supported by Squid yet (its due to arrive in Squid v4, which hasn't been released yet), which means your actually usable ciphers in the list is quite small. Just copy and paste Mozilla's ciphers in, and you will be set once squid v4 is ported to PfSense, since Squid ignores ciphers it doesn't understand.

[geijt]

That's clear and a good solution, I'll start with the changes and testing.

[doktornotor]

This looks pretty good as is. As for the custom DH params - again, there's no need to complicate the code. If someone generates their own under /etc, they will be used (see the previous PR discussion). If not, they won't. No need for checking custom directories or whatever else.

[geijt]

I've implemented the settings described at Mozilla's site. The protocols are now automatically selected based on the Modern or Intermediate compatibilty mode (SSLv2/3 are not available anymore) and only the default DHParam files are used.
I hope you like this implementation.

[btsimon97]

Thank you. This makes troubleshooting cipher suite errors (rare as it may seem it does happen) a lot easier. This looks good to merge.

[cbuechler]

2.2.x and earlier packages are no longer actively maintained. This has been merged into 2.3+