Hello,

Setup : Internet > Xeams > Exchange (Firewall mode)

I was just wondering, is the communication between senders mail server and Xeams encrypted with TLS or is the encryption only occurring between Xeams and the internal exchange server?

Whilst using starttls.com it seams Xeams is encrypting with proxied STARTLS commands but if Xeams in monitoring and checking contents of emails as they flow  (according to your site: http://xeams.com/3Modes.htm  ["In this mode Xeams acts like a firewall that sits in front of your corporate email server. Every in-bound email is checked by Xeams before it is forwarding the message to the actual email server."]

Does this not defeat the whole purpose of man-in-the-middle attack which is prevented by TLS?  I'm not too sure who is doing the TLS here? Xeams or Exchange?
If it is xeams, which logs shows this?  If Exchange is doing the TLS then how is the Xeams proxy working to check emails and their contents (for spam and filters) without decrypting the emails?

Can a little more insight be shed onto how the mechanism actually works?

Thanks guys, excellent product.

Just to confirm, I am completely aware that the contents of emails are not encrypted during TLS but the connection is. My concern is how can is email received during the TLS session during this proxy connection. Is it done at Xeams for receiving then re-started again between itself and exchange as a second session? Just a little detail please. Thanks.

Thanks

Hello Synametrics,

Just a bump on the above support request.

Thanks very much

James

Hi James, 

Thank you for asking this excellent question. Please give us some time as I will forward this question to our tier 2 support, because we want to give you an answer with detailed explanations.

Please give us about 24 hours and hopefully we will give you an answer at that time. 

James,

This is an excellent question. Thank you for asking.

You are correct when you say Xeams acts as middleman when using the Proxy server. Since SSL does not allow a middleman, you MUST use a certificate on Xeams, not on Exchange. This way the communication between the sender's SMTP server and Xeams will be encrypted. See image below.

In-bound Messages

When using the Proxy server, the certificate present on your Exchange never comes in picture. 

When two SMTP servers communicate with each other, one acts as a client and the other as a server. A certificate is only required by the end that is acting as a server. Therefore, STARTTLS will ONLY be used by sender's email server IFF you have installed a valid certificate in Xeams. When STARTTLS is not enabled in Xeams, the sender will send the message in clear.

Out-bound Messages

When Xeams needs to send messages out to another SMTP server it acts as a client. Since a certificate is NOT needed when acting as client, Xeams will always use STARTTLS even if it is not enabled for incoming. In this case, the communication between Exchange and Xeams may or may not be enabled. Out-bound communication with, for example, gmail.com will always be enabled since Google supports STARTTLS

Let us know if you need further explanation. 

Thank you for your support and response in helping to understand the procedure however I think there is a slight confusion.

If you are presently using Xeams on your demo lab and have both a certificate installed in exchange and in Xeams please browse to checktls.com and give it a try yourselves. I've attached a snippet below on what exactly is proxied across. Exchange seems to be doing the TLS and not Xeams. 

If you take a closer look you will see that Exchange is in fact explaining to the remote server "we are TLS ready" not Xeams. If you continue further down you will also see the connection is proxied with the AUTH commands and SIZE commands of the exchange server. The exchange server is replying back and serving the certificate through the proxy which is incorrect according to RFC standards.

The proxied connection shows that Exchange is sending its certificate back and not Xeams?
If Xeams was sending the certificate back it would show the external server name with checktls and not the internal exchange server name which I have masked.
If Xeams was setup in SMTP server mode and accepted the email in TLS and restarted another TLS session with Exchange your explanation would make sense.

There is some sort of man in the middle issue going on here. Why does Xeams even need to have a copy of the certificate if it simply relaying the communication down? I can definitely understand if it was running in SMTP server mode but it isn't. A further example of this is in your instructions located here:http://www.xeams.com/using-iis-cert.htm. SSL standards most certainly doesn't even allow exporting a certificate from one server and using it on another server with a different host name, A simple google search will show that. If that was the case you would need a SAN (alternate names) certificate which includes the Xeams server hostname on it. Please can you explain further? 

Can you please try this in your labs as I believe there is definitely an issue with the current setup that Xeams handles mail according to TLS RFC communication?

Please can you explain further?
Thank you for your help guys.

James,

What is the IP address of your server? Is it possible for you to call us or send us an email. Explaining this over the phone will be a lot easier. Our number is 609-750-0007 - dial 2 for support.

In any case, I am going to try to explain this for other viewers.

The SSL encryption occurs at the network layer. When a sender (checktls.com) tries to connect, a TCP/IP socket is created between CheckTLS and Xeams. This socket has no idea about Exchange. Once the connection is established, Xeams will open another socket to your Exchange. Now Xeams acts as a middleman. Whatever CheckTLS sends, Xeams forwards that request to Exchange. When Exchange replies back, Xeams sends most of the reply back. I say "most of the reply" back because some extensions supported by Exchange are not supported by Xeams and therefore, it hides them. 

This is precisely the reason why you see a 250-STARTTLS as part of the EHLO command. Try opening a connection using telnet directly to your Exchange and you will see additional verbs as part of EHLO that are suppressed by Xeams.

Xeams does not filter the Internal Server Name, SIZE and few other parameters coming back from Exchange and therefore, you see them verbatim on the other side.

This does not mean the SSL communication is between checktls.com and Exchange. The actual encryption is only between checktls and Xeams.

Thank you for your response. I will get an email out or call you a little later.

As you say, for the viewers sake;

I completely understand the socket is created which is why I was mentioning in my earlier post that it must be creating a second connection in order for this implementation to work. It is most certainly not proxying everything in one stateful connection. 

If this was the case, why are you allowed to use the same certificate from a different server detailed on your site here [http://www.xeams.com/using-iis-cert.htm] with no mention that the the certificate name must include the Xeams server as an alternative name? The TLS session would fail on validation tests if the hostname used in your IIS certificate server example above was different to your Xeams server hostname. Your site needs to mention this or at the very least mention explain that only wildcard certificates would work using those instructions. Give it a try. Export a certificate with an alternative hostname [server-name] and import it into your Xeams lab server then run a TLS session with Xeams and let me know what you guys get. In theory it would work if both machines had the same name OR it was on a SAN certificate OR you used a wild card but thats all. 

Another example is if you shutdown your Exchange server and run the same test at checktls.com you will find that the maximum the senders server can do is connect to Xeams but no TLS will take place and the test will fail. This is another indicator that Xeams is not properly implementing TLS according to standards or for that matter according to the way your explanation is.
If a socket was created (IP:Port) then at least a secure session should start and then fail on the relay of verbal messages / debug which does not occur. Give it a try for yourselves.

I'd also like to add that if Xeams was doing the TLS with the sending mail server and then opening a new socket with for delivery exchange, why cannot this new connection be in TLS too? A simple proxy ARP or ARP-on-behalf spoof could ultimately catch all the email data for inspection between Exchange and Xeams as it is unencrypted.

I am a little sceptical about the security of certificates being installed on Xeams servers.

Could you guys please clarify further?

Thank you,
James

James,

You are correct - it is NOT one stateful connection. They are two different connections.

One SSL certificate can be used on different servers, provided the host name matches. If you have a wild-card cert, that takes care of the host name problem as well. The reason we mention using "wildcard" is because the page assumes the certificate on your IIS is probably for www.yourdomain.com and the host name of your mail server will be something like mail.yourdomain.com . Bottom line: same certificate you use on Exchange can be used in Xeams, provided the host name problem is solved.

If the shutdown Exchange, the Proxy server in Xeams will also shutdown. That is because as soon as a EHLO is sent from CheckTLS, Xeams will try to open another socket to Exchange. If that second socket cannot be opened, Xeams will display an error complaining server is temporarily unavailable. This does NOT mean TLS is not working. TLS starts AFTER the EHLO command. If EHLO fails, no TLS will every occur.

I think you are confusing between SSL and STARTTLS. The port for SSL is typically 465. Any communication on this port will be 100% encrypted (even the HELO/EHLO). STARTTLS on the other hand starts with plain non-encrypted communication, checks if the receiving server supports STARTTLS (which is an option returned by EHLO command) and then upgrades the existing socket to SSL. This will be evident from looking at SMTPOutboundConversation.log . Try sending an email to gmail.com and then look at that log in Xeams. The EHLO command is sent twice. The first call will be in plain and the second will be encrypted. Additionally, gmail.com's server will only advertise STARTTLS in the first call. The second call, which is already encrypted, will not have a 250-STARTTLS as part of its EHLO results.

I forgot to answer a couple of questions: why is the connection NOT encrypted from the start?

There is a historic reason for this. When email first started, SMTP servers used to communicate on port 25 and there were no SSL certificates. Later on port 465 was introduced for SSL. However, many servers kept communicating on port 25 without encryption. There was a need to use SSL on port 25 without breaking the existing communications. That is when STARTTLS was introduced, which has the ability to start with non-encrypted communication and later upgrade the same socket to encrypt.

You said: A simple sniffing tool sitting between Xeams and Exchange will be able to watch the communication. This is correct but there is more to it:

• This tool will only be able to see the HELO/EHLO, MAIL FROM and RCPT TO command. Not the DATA command, which will hold the actual email. By default, the SMTP Proxy server runs in Async Mode. This means that it will only proxy the HELO/EHLO, MAIL FROM and RCPT TO. The original connection will be disconnected from Exchange before DATA is sent.
• If a message is considered good, Xeams will create a brand new connection to Exchange. This new connection will be visible through SMTPOutboundConversation.log and will use STARTTLS if supported by Exchange.
• If you think sending MAIL FROM and RCPT TO is a security risk, (which I don't think since everything is within your LAN), you can use the regular SMTP Server instead of the Proxy server.

Hi,

Hope you are all well.

I'll answer both posts in this one; 

Guys, we both know I was trying to explain that you need to tell users they need to use wildcard certificates or SAN certificates and not just to export their IIS certificate. It wasn't the other way round. In fact after explaining to you that you need to add that information to your site, the site now returns a 404. Read my posts above where I specifically say you need to mention this on your website.

1. TLS starts after HELO - agreed and understand.

2. "I might be confusing SSL and TLS" - Is there a need for those sort of remarks? (port 465, upgrading connection, etc.)

3. If a message is considered good, Xeams will create a brand new connection to Exchange. This new connection will be visible through SMTPOutboundConversation.log and will use STARTTLS if supported by Exchange. - Can you please explain this a little further with an illustration. From what I gather you are saying the below is occurring however your illustration above shows the connection to Exchange for last leg delivery is plain text?

gmail, yahoo, etc. > Xeams (TLS) > Check if From and RCPT valid with Exchange & AD > Yes > Drop local connection to Exchange & AD > Filter email Xeams > Start new local connection to Exchange with TLS to deliver local mail.

and...

gmail, yahoo, etc. > Xeams (TLS) > Check if From and RCPT valid with Exchange & AD > No > Drop local connection to Exchange > Drop external connection to remote server and don't filter at all.
Or
gmail, yahoo, etc. > Xeams (TLS) > Check if From and RCPT valid with Exchange & AD > No > Drop local connection to Exchange > Filter anyway, Discard email, and Drop external connection to remote server.

4. Finally, Is the connection for the LDAP lookup carried out using secure ldap or plain text?

5. I am assuming the proxy connection to AD will only work with the one server name specified, do we need to implement round robin for AD redundancy or will you be adding secondary domain controller fields we can use?

Just to clarify this before implementing on large scale if need be.


Thank you,
James

James,

I'd like to first apologize for some confusion that got created because I misunderstood your post. I interpreted your wildcard comment as a question instead of a recommendation and therefore, answered it incorrectly. We have added your suggestion to http://xeams.com/using-iis-cert.htm . Let us know if we should further modify it. The link in the earlier post ends with a ] which resulted in a 404 on your end.

Answer 2: Again I apologize. I did not mean any disrespect.

Answer 3: Here is a flow chart.

Answer 4: Yes, but only if all of the following conditions are true:

• Exchange accepts the sender and recipient
• AD is configured
• The Use Active Directory option is checked for SMTP Proxy Server

Note that until recently, AD was only used when using the regular SMTP server. However, Microsoft changed the way they reject invalid users in Exchange 2013 and 2016. They no longer reject invalid users after RCTP TO. Instead, they reject the email after DATA, which breaks the logic in Xeams. Therefore, we had to add AD integration for Proxy Server.

Answer 5: This is partially answered by #4. If you are installing this on a large scale, I'd recommend NOT using the Proxy Server but using the Regular SMTP Server for both inbound and outbound. I say that because:

• The regular SMTP server can forward messages to multiple Exchange servers on the back-end, where as the Proxy can only talk to one
• If your Exchange goes down, Proxy will go down along with it. The regular SMTP server will queue the messages until Exchange comes back up.

I also recommend checking http://www.xeams.com/clustering.htm to see how to use Xeams in a large environment.

Hello Again,

Firstly my apologies for the delay. I have been on a short business trip.

I have managed to skim read the above and now have a better understanding - thank you. In any case I will look into it with greater depth and give a detailed answer shortly.

Thank you again.

Regards,
James