Topic: Disable SSLv3 without disabling TLSv1

[PeteAUK]

Hi All,

Just got to a bit of a stumper.  Because of PCI requirements I need to disable all SSLv2 and SSLv3 on servers exposed to the outside world.  The scanning company have reluctantly allowed continued use of TLSv1 as I've quoted a defined upgrade date but aren't prepared to budge on the SSLv3 point.

I'm trying to get e-smith to disable SSLv3 but leave TLSv1 and can't fathom out how to do this, it appears as if the two are intrinsically joined together.  I'm using:

Code: [Select]

config setprop qmsmptd tlsCipher '' which I'd originally set to

Code: [Select]

HIGH!SSLv2.  Setting this to

Code: [Select]

HIGH!SSLv3 disables TLSv1 in addition to SSLv3 (thus preventing the company sending e-mails), I tried

Code: [Select]

HIGH!SSLv3:+TLSv1 which appeared to simply enable both again.

Any suggestions?  We don't have the resource to upgrade to SME v9 for some months so that's not really an option.

[Daniel B.]

Code: [Select]

db configuration setprop httpd-e-smith SSLv3 disabled
expand-template /etc/httpd/conf/httpd.conf
sv h /service/httpd-e-smith


[PeteAUK]

Code: [Select]

db configuration setprop httpd-e-smith SSLv3 disabled
expand-template /etc/httpd/conf/httpd.conf
sv h /service/httpd-e-smith


Thanks but this is for httpd (which I've actually disabled externally).  I need to basically do the same on qpsmtpd

[Daniel B.]

Then you're out of luck, you have to upgrade to SME 9

[Jean-Philippe Pialasse]

To complete Daniel answer and explain why it is not possible:
Perl modules necessary for this are too old on RHEL5 / CentOS5 / SME8.
It would necessitate to update at least perl-IO-Socket-SSL and perl-SSLeay and meet all the requirement of the new versions of the modules. Also it would need to patch qpsmtpd to allow TLSv1.1 and TLSv1.2.

SME8 and upstream distributions are in maintenance mode only, and attack on TLSv1 have been  only shown on HTTP with limited control of the client.

Unfortunately, to disable the use of TLSv1 you need to filter the cipher that are the same than the one of SSLv3.

As a workaround :
- you can just disabled encryption on smtp server
- you can set a second SME v9 aside to delegate the mails, either on a spare hardware or as a VM in your current SME with virtualbox contribution.

[PeteAUK]

Thanks for the replies.  Going to have to take a long look at this as an upgrade to v9 isn't a five minute task and we were considering holding out until v10 arrives (which will give us a bit more longevity on end-of-life for CentOS)

[Stefano]

no, you're wrong.. at the moment SME10 is in early alpha stage, and there's no release data set.

if you really need this feature you must move asap to SME9.. the only way to do it is backup and restore

if you're thinking to move to a new hw too, there are other ways to do the migration, minimizing the services' downtime

[Jean-Philippe Pialasse]

I second Stefano on this,

SME 10 is really early alpha, and we can not honestly give any planned date for its release.

It depends on too many factors including : number of devs and their free time (none are paid), new functionalities that could take time to insert ( the biggest will be to change the server-manager to something more modern), but currently a big blocker is the lack of persons involved in testing to validate changes and find broken features. The good news is that any body able to install SME can participate.

[PeteAUK]

Hi Guys,

Thanks for confirming this.  I've managed to get exceptions for PCI as SME is in it's own DMZ (thus not a security issue for card payments), but moving off SME8 has now risen in priority.  As a general company rule we stick to "even versions", so we minimise the amount of time we spend performing upgrades and learning a new version which is why we were looking at SME10 for the next upgrade (we were aware it was only in early alpha with an unknown release date).

Our current set up of SME is on a VM machine so there are quite a few things to consider when upgrading to SME9 as we can't simply plug an external harddrive in to do a backup for example (which includes over 50 mailboxes and current footprint of over 110Gb).  As I say it's something that is quite time (and thus cost) intensive so we need to make sure that we've all our ducks in a row before doing anything.

thanks again!

[Jean-Philippe Pialasse]

If you are running on a VM, this should be even more easy.

The backup and restore does not really check for USB connection as a result you can use a virtio or virtual sata drive that you can connect after the initial installation of SME9 , when you are asked for backup to restore.

In a similar way you can backup using the console in command line after plugin a virtual drive big enough.

Pay attention if you have done configuration beyond SME normal configuration that only a few paths are backuped this way.

The other good news with vm is you can more easily test your migration aside.

I am certain that the others would have some other feedbacks for this.



 

[PeteAUK]

Well I've managed to get SME 9 upgrade moved higher on the to do list.

Completely agree that VM should be easier - the extra complication is we're low on space on it so need to move instances round before we can start spinning up a large enough instance.  Like I've said it's not "straight forward" but mostly due to issues falling outside SME (which has had various modifications done to it over the years).

thanks