Bug #7222
closed
Encryption No Longer Enforced for Email Notifications
Added by NOYB NOYB almost 8 years ago.
Updated almost 8 years ago.
Description
The "Enable SMTP over SSL/TLS" option does not enforce the use of encryption.
Previous versions also had "Enable STARTTLS" option which made the pfSense email client require the SMTP server to support STARTTLS and use SSL/TLS encryption.
Details of the issue and potential fix are available here:
https://forum.pfsense.org/index.php?topic=118183
Please return option to have pfSense client require encryption.
That wasn't worded very well. Strike that first sentence. This has nothing to do with the "Enable SMTP over SSL/TLS" option.
Lets try it again...
Previous versions had an "Enable STARTTLS" option implemented such that when enabled the pfSense email client would require the SMTP server to support STARTTLS and use TLS encryption. Without this option there is no way to ensure/force the use of STARTTLS and TLS encryption.
That leaves it vulnerable to STRIPTLS attack because the pear-mail client does not require TLS be used and will fall back to plain text if server does not support STARTTLS. ISP's have been known to be fond of using STRIPTLS.
Opportunistic TLS - Weaknesses and mitigations (STRIPTLS)
https://en.wikipedia.org/wiki/Opportunistic_TLS#Weaknesses_and_mitigations
Would like to see this option restored and used for the client to force/require TLS when STARTTLS is enabled.
A discussion of the issue and a potential fix are available here:
https://forum.pfsense.org/index.php?topic=118183
- Target version changed from 2.4.0 to Future
We switched over to the Pear Mail package and at the moment I'm not seeing any equivalent option in their code. It would need to be added upstream before we could pick it up.
Why can't pfSense customization be made to the pear Mail package, like is done for some others packages, to add the require_tls param like shown in the pear Mail patch referenced in the thread?
Well, I'd hazard to say because it's just another thing to maintain with pretty much no gain? Want to be sure TLS is used? Use explicit and not STARTTLS.
Kill Bill wrote:
Well, I'd hazard to say because it's just another thing to maintain with pretty much no gain? Want to be sure TLS is used? Use explicit and not STARTTLS.
I want to continue using STARTTLS like current system and config is doing. Probably others will also. See no reason for the require STARTTLS capability to be removed. The param can be added to pear mail reasonably easily.
- Status changed from New to Needs Patch
Lobby to the PEAR crew to import the patch and we'll add support once it's in there. We have maintained a lot of custom code/patches in the past but it's a lot of technical debt to take on, and we are trying to keep that to a minimum.
As you mentioned on the thread "Don't want the liability of this on my shoulders." -- this is the responsibility of PEAR, not any of us. Same with your other points there. These are all things the PEAR maintainers need to take on and test, not us.
Jim Pingle wrote:
Lobby to the PEAR crew to import the patch and we'll add support once it's in there. We have maintained a lot of custom code/patches in the past but it's a lot of technical debt to take on, and we are trying to keep that to a minimum.
As you mentioned on the thread "Don't want the liability of this on my shoulders." -- this is the responsibility of PEAR, not any of us. Same with your other points there. These are all things the PEAR maintainers need to take on and test, not us.
That's a reasoned explanation I can accept. Don't like it but can accept it. Thank you.
Hope there will be a release note to give people a heads up that STARTTLS is no longer enforced. To let them know if they are upgrading systems that currently uses STARTTLS option, the "Enable SMTP over SSL/TLS" option is now the only way to ensure encryption is used.
I will be implementing the STARTTLS option anyway. Shame it won't be available too others. My guess is pear Mail will never be patched to fix this STRIPTLS security hole. As usually, once again security takes a backseat.
Also available in: Atom
PDF