TLS For All CentOS Websites But Not For SMTP?

Home » CentOS » TLS For All CentOS Websites But Not For SMTP?
CentOS 12 Comments

Hello everybody, I just got the email about the enforcing of HTTPS for the CentOS Websites which I really appreciate:

„The CentOS Project infra team has decided to implement TLS wherever we can (…)”

Does anybody know if and when mail.CentOS.org will be able to deliver its mails with STARTTLS? There seems to be no support for STARTTLS at all:

$: openssl s_client -connect mail.CentOS.org:25 -starttls SMTP
(…)
didn’t found starttls in server response, try anyway…

12 thoughts on - TLS For All CentOS Websites But Not For SMTP?

  • e-mail by its very design is not secure, SMTP creates “Man In The Middle” at every server along the way.

    Signed messages are the only way to know they haven’t been modified in transit between sender and recipient.

    DKIM does that if you trust it won’t be modified on your server before it is applied, but even that doesn’t work with mail lists because mail lists do modify the message.

    I’m not saying they shouldn’t implement TLS on the list server, just not sure what the privacy or security benefit really would be.

  • DANE exists and mail servers like postfix support this. My logfiles show me that mail.CentOS.org delivers straight to me without any servers along the way.

    Encryption ensures that third parties simply cannot follow their “collect all” strategy.

  • But it’s a public mailing list??

    I can understand why you may want to send some mail encrypted point to point, but not when you then publish said mail on a publicly accessible archived list. It’s just adding unnecessary overhead.

  • No, it’s making the job harder for the mentioned third parties with their giant “we take everything we can” strategy. Encryption should become the default for every possible protocol regardless of the content.

  • Am 19.08.2015 um 20:02 schrieb Ned Slider :

    CentOS.org’s MX is for sure not only for mailing lists …

  • Thanks for the comment.

    As said, we were targeting first the websites, but we can also investigate what would be needed and the possible impacts of implementing that for SMTP traffic. But, as other people said it too, it depends on what you want to secure/encrypt, and gnupg can also be used for that, despite the SMTP
    server[s] included in the chain.

    My (personal) opinion is “if you want to secure/encrypt”, use gpg. Adding TLS on top of SMTP for the transport itself can be a good idea. Let me just start a thread with the other guys and see what we can come with. That will not be priority #1 though, as we’re also working on other things, like using FAS for central auth for resources like cbs.CentOS.org and git.CentOS.org.

    Kind Regards,

  • That’s right if you want to hide the content. But this leaves the metadata of the communication clear to see for third parties. Using transport encryption is the only way to at least make this very hard to collect.

    JFTR: I am not concernded about this mailing list and the traffic. It’s just my opinion that we nowadays should use encryption and authentification as much as possible and make this the default.

  • I 100% agree with gpg. TLS/SSL I would only consider necessary if you have to authenticate with your SMTP server for having it send your message for you. For everything else as far as SMTP is concerned TLS/SSL does not add anything thus is not necessary IMHO.

    Just my $0.02.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • However, this is a mailing list. And all messages sent through this mailing list are archived and published as web documents. It seems to me that insofar as CentOS ML comsec is concerned STARTTLS would not add any measurable degree of security or privacy.

  • But there is a fair point that most archives of mailing lists on the web make some attempt to hide the e-mail addresses from spambots.