Mailing List Archive

Safe from what ?

John Simpson's site has the best information and it's yet to be condemned
by anyone because it is solid.

Rephrase your question

On 22 Jan 2015 20:14, "kirk" <kirk@icapsolutions.com> wrote:

> Ive recently installed qmail following https://qmail.jms1.net/
> patches/combined-details.shtml with qmail-1.03 and
> qmail-1.03-jms1-7.10.patch, along with courier-imap-4.2.0 to enable access
> to pop3d-ssl and imapd-ssl.
> I've been questioned several times now about how safe it is to communicate
> to the server and sending mail with sensitive data. With the configuration
> from above and the config files all set to "force TLS", how safe is it to
> send emails with company sensitive data? I'm under the impression that we
> can pass sensitive data to our own local domain, ie userA@mydomain.com
> can pass an email to userB@mydomain.com without compromising anything as
> long as all communication to mydomain.com is TLS?
>
> Any insight?
>
> Thanks in advance,
> Kirk
>
>

> Ive recently installed qmail following
> https://qmail.jms1.net/patches/combined-details.shtml with qmail-1.03
> and qmail-1.03-jms1-7.10.patch, along with courier-imap-4.2.0 to enable
> access to pop3d-ssl and imapd-ssl.
> I've been questioned several times now about how safe it is to
> communicate to the server and sending mail with sensitive data. With the
> configuration from above and the config files all set to "force TLS",
> how safe is it to send emails with company sensitive data? I'm under
> the impression that we can pass sensitive data to our own local domain,
> ie userA@mydomain.com can pass an email to userB@mydomain.com without
> compromising anything as long as all communication to mydomain.com is TLS?
>
> Any insight?

As a general rule, no matter how secure the transfer protocol itself, you
should assume that email is an insecure medium to transmit information
that is not itself encrypted. While you are theoretically correct about
emails sent within your server being able to be transmitted encrypted
end-to-end, there's no on-server encryption, nor is it possible to
guarantee end-to-end encryption if you allow any unencrypted
communications (like inbound emails from other servers that don't support
TLS). Also, once it leaves your server, you have no control over whether
it is sent over an encrypted channel or not.

Basically, if you want to send information vi email in a secure manner,
you need to encrypt the message itself, either using S/MIME (or something
like that), or by attaching the message as an encrypted file. Better yet,
don't send sensitive information over email. Any other way of sending
cannot be guaranteed as being secure.

Josh

Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
josh@honorablemenschen.com

Hi Kirk,

I am not 100% sure, whether I have understood your question right, nor am I in a position to claim anything about the qmail patch you mentioned. Anyway, since my Spamcontrol implementation for qmail provides practically the same level of ‚confidentially‘ let me explain:

1. A good overview of TLS an qmail interacting with this an be found here: http://www.fehcom.de/qmail/smtptls.html
Ok this is my solution but …

2. all qmail TLS implementations (I know about) depend on OpenSSL and it’s features/weaknesses (the OS plays a role as well).

3. The ’strength’ of confidentiality’ (apart from implementation errors) can be judged by means of the TLS Cipher. At least in my implementation this is visible in the logs and the email header.

4. TLS key generation is determinable. The only way out is to use initially random numbers (kept secret) provided by the Diffie-Hellman key (ephemeral) exchange — DHE — (occasionally called ‚perfect forward secrecy‘).

5. This only accounts for the *transport* of the mail message. How to intercept it at the source or destination is out of scope. Without target authentication even DHE might the subject of a Man-in-the-Middle attack.

6. Mutual authentication is possible by means of client certificate exchange. At least my implementation supports this.

regards.
—eh.



Am 22.01.2015 um 17:52 schrieb kirk <kirk@icapsolutions.com>:

> Ive recently installed qmail following https://qmail.jms1.net/patches/combined-details.shtml with qmail-1.03 and qmail-1.03-jms1-7.10.patch, along with courier-imap-4.2.0 to enable access to pop3d-ssl and imapd-ssl.
> I've been questioned several times now about how safe it is to communicate to the server and sending mail with sensitive data. With the configuration from above and the config files all set to "force TLS", how safe is it to send emails with company sensitive data? I'm under the impression that we can pass sensitive data to our own local domain, ie userA@mydomain.com can pass an email to userB@mydomain.com without compromising anything as long as all communication to mydomain.com is TLS?
>
> Any insight?
>
> Thanks in advance,
> Kirk
>
>

---
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: 7E4034BE

Thus said kirk on Thu, 22 Jan 2015 08:52:42 -0800:

> I've been questioned several times now about how safe it is to
> communicate to the server and sending mail with sensitive data.

How many SMTP servers which use TLS are not susceptible to
man-in-the-middle attacks?

Andy
--
TAI64 timestamp: 4000000054c1b93a

Am 23.01.2015 um 03:59 schrieb Andy Bradford:
> Thus said kirk on Thu, 22 Jan 2015 08:52:42 -0800:
>
>> I've been questioned several times now about how safe it is to
>> communicate to the server and sending mail with sensitive data.
>
> How many SMTP servers which use TLS are not susceptible to
> man-in-the-middle attacks?

Most user agent I know check the presented certificate against the
server settings and the trust list, so as long as you dont bork your
client setup - MITM should not be a problem.

But as said by others, if you transmit sensitive data, use end-to-end
encryption or dont use email

Oli

Ad: my company can provide help with end2end encryption =)

--
Protect your environment - close windows and adopt a penguin!

On Thu, Jan 22, 2015 at 08:52:42AM -0800, kirk wrote:
> With the configuration from above and the config files all set to
> "force TLS", how safe is it to send emails with company sensitive
> data? I'm under the impression that we can pass sensitive data to
> our own local domain, ie userA@mydomain.com can pass an email to
> userB@mydomain.com without compromising anything as long as all
> communication to mydomain.com is TLS?

I think the most sensitive thing is your company auth credentials,
don't send these in plain text. Configure the mail clients to use
nothing less than TLS v1.2 if possible.

--
Best regards,
Ed http://www.s5h.net/

Thus said Oliver Welter on Fri, 23 Jan 2015 08:02:30 +0100:

> > How many SMTP servers which use TLS are not susceptible to
> > man-in-the-middle attacks?
>
> Most user agent I know check the presented certificate against the
> server settings and the trust list, so as long as you dont bork your
> client setup - MITM should not be a problem.

But the question I asked was how many SMTP servers (e.g. between
internet facing MTAs) check against the trust list and are configured to
refuse to deliver a message if said trust verification fails?

> But as said by others, if you transmit sensitive data, use end-to-end
> encryption or dont use email

Yes, on this we can agree.

Thanks,

Andy
--
TAI64 timestamp: 4000000054c27598

Am 23.01.2015 um 17:23 schrieb Andy Bradford:
> Thus said Oliver Welter on Fri, 23 Jan 2015 08:02:30 +0100:
>
>>> How many SMTP servers which use TLS are not susceptible to
>>> man-in-the-middle attacks?
>>
>> Most user agent I know check the presented certificate against the
>> server settings and the trust list, so as long as you dont bork your
>> client setup - MITM should not be a problem.
>
> But the question I asked was how many SMTP servers (e.g. between
> internet facing MTAs) check against the trust list and are configured to
> refuse to deliver a message if said trust verification fails?
>
As the OP asked for - for my understanding - sending mails "inside" his
local domain/server, this does not apply. You can never trust any
information going about servers you dont control, even if the
transmission to you server is "secure", you dont know what happened earlier.

Oliver


--
Protect your environment - close windows and adopt a penguin!

Am 23.01.2015 um 17:23 schrieb Andy Bradford <amb-sendok-1424622199.lpdmefpdkmpcengpecbg@bradfords.org>:

> Thus said Oliver Welter on Fri, 23 Jan 2015 08:02:30 +0100:
>
>>> How many SMTP servers which use TLS are not susceptible to
>>> man-in-the-middle attacks?
>>
>> Most user agent I know check the presented certificate against the
>> server settings and the trust list, so as long as you dont bork your
>> client setup - MITM should not be a problem.
>
> But the question I asked was how many SMTP servers (e.g. between
> internet facing MTAs) check against the trust list and are configured to
> refuse to deliver a message if said trust verification fails?
>

What is trust ?

In OpenSSL terms we have

- a ‚key store‘ where usually our own private keys are stored,
- a ‚trust store‘ where root and intermediate certs are stored, and perhaps
- an ‚anti trust store‘ — the static list of revoked certs.

During *verification* the client checks the received certs from the server against technical issues and perhaps the ‚trust store‘ — if advised to so.
AFAIK there is no place in the protocol to indicate the latter. Thus, whether the verification includes - or does not include - the last step, is a matter of local policy.

To be more clear: The quality of the decision and the chosen scheme and parameters can not be checked by somebody sitting remote. Even in my own implementation, neither the email header nor the logs tell anything about it (I should certainly change this).

On the other hand: A lot of MTA certs are self-signed and are put in place just to comfort the protocol — and are simply disregarded by the client.
Given the broken X.509 trust chain these days, this makes sense.

To conclude: We have lost trust in the X.509 trust chain.

Maybe DANE would be better solution.

regards.
—eh.



---
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: 7E4034BE