I'm working on implementing an Exchange 2010 solutions which includes Outlook Web Access, Exchange ActiveSync and Outlook Anywhere. These services use SSL and would be presented on the Internet so our users can access them externally. I'd obviously need to protect the server (CAS role) that these services operate on. My question is what threats are posed by SSL connections? If I were just to do a port forward on the SSL connection directly to the OWA and EAS server what risks are there? Do I need to do IDP on the encrypted traffic? Thanks

  • +1 for phrasing the question in a risk context! There is a tremendous difference between "What sort of threats can use SSL connections?" (effectively all of them), and "What threats are posed by SSL connections?"
    – MCW
    Mar 13, 2013 at 14:02

2 Answers 2


If your intrusion detection system sees anything worth reporting while looking at a SSL connection, then it is not SSL, or is very poorly implemented. By construction, SSL is meant to provide a tunnel for confidential data, i.e. it is very opaque from the outside.

Generally speaking, SSL is not a threat, it is a protection measure against threats. In particular, it prevents evil attackers from inspecting, measuring, eavesdropping on, tinkering with, and forging the data.

Some sysadmins get nervous in the presence of SSL because it prevents them from inspecting, measuring, eavesdropping on, tinkering with, and forging the data.

The external services of Exchange are designed to be exposed to the public at large, which is why they use SSL by default, as they should be.

  • I don't work with IDS much, but aren't there IDS systems available that you can give the server private key so that they can examine SSL streams? If not, I would certainly say that it would be a risk factor (if a fairly minor one in comparison to not using SSL) that SSL was bypassing the IDS for monitoring for attacks against Exchange. Mar 13, 2013 at 13:38
  • @AJ that might be the case, only if the IDS would have anything intelligent to say about Exchange's protocols.
    – AviD
    Mar 13, 2013 at 13:41
  • @AJHenderson: in addition to what AviD says, note that having the server private key is not necessarily sufficient to decrypt the data, in case the server uses a DHE cipher suite.
    – Tom Leek
    Mar 13, 2013 at 13:46
  • I know I can implement IDS systems that scan encrypted traffic by setting them up with the SSL certs but is that necessary? What is the likelihood of a threat, on a client, hijacking the SSL connection, say to OWA, and then attacking the CAS server. I appreciate there are quite a few factors to consider in that question as environment is part of the probability. Mar 13, 2013 at 14:00
  • To "hijack the SSL connection" you more or less have to hijack either the client browser or the server, at which point you have bigger problems. If the client is hijacked, then anything he does can be seen and altered by the attacker. The server itself should defend against that -- it is part of the security model of OWA to not trust the client for not doing anything evil. I.e. a complete client hijack means that all the user emails become known to the attacker, but the server will still be safe.
    – Tom Leek
    Mar 13, 2013 at 14:12

An SSL connection is pretty much just like a normal connection in terms of what people can do with it. The only difference is that it blocks attackers that are external to the communication. You know that the client on the SSL tunnel is always the initiator of the SSL tunnel, but they can still send whatever they want over the tunnel, so you would still want to do IDS on the tunnel just like you would for an open HTTP connection.

  • That's what I was thinking, I appreciate SSL is a protection in itself but if a client has established a session how much risk is there that a threat, on that client, will use the SSL session to attack the server your connected to. I understand Exchange is hardened to this but I'm not sure of the scope or probability of the risk. Thanks for your replies. Mar 13, 2013 at 13:56
  • @Ihaveaquestion - It doesn't even have to be a threat on the client. Simply a malicious client could connect or attempt to connect. You should pretty much never trust the client and while SSL makes sure your exchanges are not watched, it still doesn't mean you can trust the client unless you are using client certificates and a much more thorough security model that protects the clients such that they can be trusted. As far as client trust, SSL is no different from a standard HTTP connection. Mar 13, 2013 at 16:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .