TLS/Exchange 2003 and Postini

I have to configure TLS encryption between us and our client. Here is a little plan I wrote for myself to figure out it with Postini guys, but if you have answers or any other input from your experiance, that would be much appreciated.

**********

If we 1) Encrypt the traffic using TLS and 2) Postini allows this traffic through un-scanned (because it cannot “open” encrypted traffic), then we are facing the security risk of passing malware/viruses/spam to and from our client. We don’t have any Antivirus Mail scanning on Exchange server, which exponentially increases the risk. [I know it HAD to be installed, as absurd as it sounds - it is not my call]

 

Question we have to verify with Postini/MXToolbox guys:

1.      Do Postini have issues with allowing TLS-encrypted traffic on their network

2.      Is there a way for them to un-encrypt the traffic in order to scan it and then encrypt it back and pass it to our client.

3.      If #2 is not an option – can they offer hosted solution for encrypted the traffic between us and client domain [Message Labs for example provide this type of service]
elo-miloAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Wonko_the_SaneCommented:
1. TLS is quite common, so I doubt it. But it only works when both sending and receiving hosts are configured accordingly.

2. TLS encrypts the email only while it's being transmitted. The actual email is not encrypted and it can still be scanned for malware etc. There is no additional security risk when using TLS, however it only encrypts the traffic while it's on the wire.
elo-miloAuthor Commented:
"TLS encrypts the email only while it's being transmitted. The actual email is not encrypted and it can still be scanned for malware etc. There is no additional security risk when using TLS, however it only encrypts the traffic while it's on the wire."

- This where I have a deadlock... On the Exchange server when you enable TLS you actually install cert to encrypt the traffic. That means that from my Exchange box traffic is sent to Postini in the encrypted format. When it arrieves to Postini it has to be decrypted so they can scan it. But they cannot decrypt it beause they do not have our private key or our cert for that matter.
It looks like it works in a different way, not the way I think - can you explain where do I go wrong here?
Wonko_the_SaneCommented:
You are confusing some concepts here.
TLS basically works like SSL (HTTPS). Both receiving and sending servers need to offer it. I don't want to get into too much detail, but it comes down to that the servers negotiate a symmetric key, similar to what a browser does when you access an HTTPS site. The EMail itself never gets encrypted, the TRAFFIC is encrypted, and both sending and receiving servers have the keys to decrypt the traffic.

It would be different when using S/MIME, here the actual EMail gets encrypted.

Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

elo-miloAuthor Commented:
"TLS basically works like SSL (HTTPS). Both receiving and sending servers need to offer it."

----- What I don't understand is - whether the mail is encrypted or only the traffic - it still encrypted and in order to scan you need to decrypt it, right? So how postini does it?
(don;t be afraid to go o into the detail, I can handle it)
Wonko_the_SaneCommented:
The Mail does NOT get encrypted. Only the traffic. The payload of your network packets, if you will. This makes it impossible to gain access to the mail using a network sniffer, but that's about it.

The encryption happens between your server and the postini server or the postini server and the sender. Both servers know the key since they talk to each other over an encrypted connection. The traffic is encrypted - this means the data packets on the network are encrypted, nothing else. This happens only between the two SMTP servers and both of them are able to encrypt and decrypt that traffic. For a mail client or an antivirus software nothing is encrypted.
elo-miloAuthor Commented:
OK, let me get it straight:

1. "The Mail does NOT get encrypted. Only the traffic. "
----- You mean the the CONTENT of the mail is not encrypted, but the traffic is. Right? (Sorry if I'm being slow)

2. "This makes it impossible to gain access to the mail using a network sniffer, but that's about it."
--- I was always under impression that encrypted traffic cannot be seen in sniffers. Do I miss something here? (PLease take a look at my next question - it will probably explain where confusion stems from)

3. "The encryption happens between your server and the postini server or the postini server and the sender. Both servers know the key since they talk to each other over an encrypted connection. "
---- a. That is correct if I by the service from postini that tkaes care of that, right? (In this case we should forward them our private key I guess)
      b. I was always convinced that we configure TLS betwen to endpoint Exchange servers (us and client) and that Postini simply pipes the traffic through untouched. [This is why I was wondering how they are able to peek inside thtraffic that they just pass through)
So which option we're talking about here - a or b?
Wonko_the_SaneCommented:
1. Right. The network traffic is encrypted.

2. You can still see the packets in a sniffer, but it will make no sense - since it's encrypted

3. a would apply. You cannot route an encrypted TLS encryption through another relay server, since a TLS connection is always between two SMTP server. So for your communication to be encrypted everbody involved would have to use TLS: You, Postini, and sender/recipient on third party. Basically this would mean that the content is still visible to Postini. If you want your mail to be encrypted all the way, you need S/MIME or PGP, but it is a different technology. Here the message body gets encrypted, usually by the mail client. But again, both parties need to be setup for S/MIME to work/

I quote RFC 3207:
It should be noted that SMTP is not an end-to-end mechanism.  Thus,
   if an SMTP client/server pair decide to add TLS privacy, they are not
   securing the transport from the originating mail user agent to the
   recipient.  Further, because delivery of a single piece of mail may
   go between more than two SMTP servers, adding TLS privacy to one pair
  of servers does not mean that the entire SMTP chain has been made
   private.  Further, just because an SMTP server can authenticate an
   SMTP client, it does not mean that the mail from the SMTP client was
   authenticated by the SMTP client when the client received it
elo-miloAuthor Commented:
OK, I het much better understanding now. Thanks.
A final question though:

1. . "So for your communication to be encrypted everbody involved would have to use TLS: You, Postini, and sender/recipient on third party."
---- Does that mean that it works like that:
a. We by a certificate [or generate our own]. We install it on our sever for TLS connection
b. We send our key to Postini - so they will be ably to decrypt the traffic. Once traffic is decrypted they scan it for viruses and for spam
c. Then Postini encrypts the traffic with TLS (this timne they use the key provided by our client) and send it to the client's Exchange
Is that the way it flows?

2. "because delivery of a single piece of mail may
   go between more than two SMTP servers, adding TLS privacy to one pair
  of servers does not mean that the entire SMTP chain has been made
   private."

---- My understandinf of the main flow is like this:
a. SMTP server A needs to sent mail to SMTP server B.
b Server a looks for MX record of the server B, once found
c. The traffic is routde over the internet to the SMTP server B
So, even though the traffic goes through many routers over the internet, there are only 2 smtp server involved
It looks like I'm worng on this one as RFC makes the point of multiple SMTP servers. Can you give an example of commnication that hits multiple SMTP servers along the way?

P.S. The topic got a bit more complicated than I thought it would be initially. Can I bump the number of points for it to 500? (I just joined, but I think the more point weight it has the more benefit you get form it, right?)

Thanks.
elo-miloAuthor Commented:
500 is assigned,
Wonko_the_SaneCommented:
1. No! :)
There is no certificate or key exchange necessary. IF postini does TLS this will all happen automatically. But ONLY for people that have TLS enabled themselves. Again, think of it like HTTPS. When you open a secure website, you don't have to get a private key or something like that first. Your client encrypts a session key with servers public certificate, only the server can open and decrypt that session key, and from that point on everything will be encrypted using that session key that is known to both machines. The key is only valid for the session. Next time you connect, same thing happens.

2. yes, that's correct, but it's not about network routing; when it comes to "normal" SMTP traffic it's often only 2 SMTP servers.
But take your Postini example: Now it's three SMTP Servers, right?   Sender ---> Postini ---> You
So while you may be able to control the "Postini --> You" there is now way to guarantuee that the Sender --> Postini way is encrypted also. Also if you send mail you can't be sure that the MX record is not just some kind of relay that forwards it to another server.

Using TLS is a good idea. It doesn't hurt, it's pretty easy to implement. But it does not provide End-to-End protection. It really depends on what you are sending and what your goal is. If you have highly confidential material and you need to make sure that only the intended recipient can see it, the you need to look at S/MIME or PGP. If you want the traffic over the Internet to be encrypted, then TLS is fine, but needs to be implemented by all involved parties.









Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
elo-miloAuthor Commented:

: Again, think of it like HTTPS. When you open a secure website, you don't have to get a private key or something like that first. Your client encrypts a session key with servers public certificate, only the server can open and decrypt that session key, and from that point on everything will be encrypted using that session key that is known to both machines. The key is only valid for the session. Next time you connect, same thing happens.

------ So let’s apply the same logic to server-to-server connection with TLS. There are possibly 2 scenarios, meaning I can understand your explanation in 2 ways:

FISRT ONE:

1. “Your client encrypts a session key with server’s public certificate.”
----- My Exchange establishes a session to Postini, grabs Postini’s public key and encrypts the traffic with it.
2. “only the server can open and decrypt that session key”
----- So the traffic encrypted with Postini public key is sent from my server to Postini server. Postini can decrypted as it has a private key
3. Decrypted traffic is scanned and then the same type of session is established between postini and ou client
[In this case I don’t understand why do we need to install certificate on our server if it is not used for encryption]

SECOND ONE:


1.       ----- My Exchange establishes a session to Postini, grabs Postini’s public key. Then it encrypts the traffic with it and produces session key, which is sent to Postini
2.       Postini decrypts the traffic with the session sent from my exchange key and scans it
3.       Then what happens when Postini needs to send it to the destination server (our client)?
 
P.S. I did my CISSP 5 years ago and seems to be completely flushed from my memory :)
As you can see I'm really struggling to understand it.  
 
elo-miloAuthor Commented:
I guess I exhaused your patience. I bit strange for a paid service, but I'd like to thank you for discussion anyway. Points are awarded.
elo-miloAuthor Commented:
Thanks.
Wonko_the_SaneCommented:
Uhm I don't get paid for this. And I repeated what I said several times.

I honestly am running out of ideas on how else to put this. Without all the technical details, only the NETWORK TRAFFIC is encrypted between the two SMTP servers WHILE THEY TALK to each other. No private keys need to be exchanged manually. When Postini forwards your mail (which is not encrypted) it will depend on what Postini and the recipient's server do. If they also support and use TLS then again, only the network traffic is encrypted. If they don't nothing is encrypted.



elo-miloAuthor Commented:
Ok, I was under impression that if I pay for membership then experts are being paid too.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.