"Deep Exchange 2013"15 TLS Transport Layer Security

By default, SMTP traffic is not encrypted, which leads to e-mail communication on the public network as if it were broadcast, and anyone who intercepts the message can easily read its contents. But there are many sensitive messages in the real world that are sent by mail, so one way to secure the message is to use the Transport Layer Security Protocol (Transport layer safety) to provide the encryption of the SMTP traffic in transit, TLS-protected SMTP traffic can make it impossible for an interception/eavesdroppers to read the contents of the SMTP traffic, but it provides protection only during the transfer process and cannot be provided for messages that have reached the destination server or are on the sender's local server.

There are two ways to allow Exchange to use TLS, the first and simplest, called opportunistic TLS, which means that exchange has the opportunity to enable TLS when it is available (actively using TLS on the end server), and the opportunistic TLS feature is always on by default. You will also use the self-signed certificate that is generated when Exchange is installed (if you do not specify a certificate). Exchange 2013 also actively attempts to implement TLS for all remote connections.

The other is mutual TLS, although TLS is a transport layer of encryption, but if each server verifies the identity of the server by verifying the certificate provided by another server, TLS can also be used as a verification method. Lync is based on Mutual TLS, and of course exchange can be configured as such.

Opportunistic TLS does not validate the validity of a certificate, and there is a self-signed certificate that is considered OK or even an expired certificate. The application requirements for mutual TLS are stricter because exchange carries out a full certificate check, including the timeliness of the certificate, viewing the publisher's certificate revocation list, and so on.

It is worth mentioning that Exchange 2013 is using TLS V1.2, the latest TLS, and other mail servers may not be able to support this version, so during the negotiation of TLS, both parties will declare their own supported version. The cryptographic algorithms that are used in TLS versions and TLS sessions that are provided and accepted on Microsoft Exchange are controlled by the Windows secure channel subsystem (that is, Schannel), about how to view or modify the encryption algorithm that Windows uses. You can refer to this TechNet article: https://technet.microsoft.com/en-us/library/cc784149 (v=ws.10). aspx Although this article indicates for Windows 2003, but it still works in the current version.

Basic TLS

TLS is actually enabled between all MBX transport services (TechNet description is mandatory), and SMTP Ehlo is sent to a TLS-enabled server, and a STARTTLS command is included in the response that the sender receives. Know that you can start the TLS negotiation, which is a very simple way to test whether the remote server accepts TLS traffic, that is, telnet to the other's SMTP listening port, send a EHLO to see if the other party will return STARTTLS.

650) this.width=650; "title=" image "style=" border-top:0px;border-right:0px;border-bottom:0px;border-left:0px; " Border= "0" alt= "image" Src= "http://s3.51cto.com/wyfs02/M01/70/23/wKiom1WyImPjLv6oAAEZnFcT2eQ002.jpg" height= "268" />

Configuring the Send connector/Receive connector using TLS is simple, using Set-sendconnector or Set-receiveconnector with a-requiretls $True to open the TLS option for that connector. Another parameter is-tlscertificatename, which specifies a function certificate for TLS for this connector, and if you do not specify this option, default Exchange uses the certificate that you previously assigned to the SMTP service for TLS authentication. If more than one certificate is applied to SMTP, then Exchange will make an optimal certificate selection, first select a user alternate name has the server FQDN of the certificate, if not selected, there are multiple certificates to meet this condition, then according to the valid date of the certificate, select the most recent one to use.

If you need a Send connector to avoid TLS, then just set-sendconnector with a-ignorestarttls parameter, when this option is turned on, the Send connector will not announce that it supports TLS or send STARTTLS to the other server. If you need a receive connector that does not advertise or does not accept TLS, use the SUPPRESSXANONYMOUSTLS parameter on the back of the set-receiveconnector. Note If you turn this option on for the default receive connector, mail flow within your organization is interrupted because the Exchange 2013 design must use TLS inside your organization.

You can also specify the protection level of TLS that is applied on the connector, with the default TLS protection level of only encrypted transport (ENCRYPTIONONLY). Can be controlled by the Tlsauthlevel parameter, which is a total of three levels:

• Encryptiononly: The default means that the connector should use TLS to encrypt the transmission without attempting to validate the certificate.

• Certificatevalidation: Certificate validation, including transport encryption and basic certificate checking. Both sides have each other's credentials, and they verify the certificate chain and valid date, revocation list, and so on.

• Domainvalidation: Domain authentication, the most secure level. Includes transport encryption and certificate checking, and verifies that the FQDN contained in the certificate conforms to the Tlsdomain parameter in the Set-sendconnector (without using this parameter, the sender's SMTP domain is matched. ）

For example, you need to confirm that TLS is used for domain authentication when you exchange mail with Microsoft Outlook.com:

Set-sendconnector–id "ex01\outlook.com" –tlsauthlevel domainvalidation–tlsdomain protection.microsoft.com

If it is a receive connector, the parameters are not-tlsauthlevel, but-tlsdomaincapabilities.

Using domain security

Domain security is a feature set of technologies that make mutual TLS useful and manageable, such as certificate management, connector functionality, and Outlook client behavior.

A server configured to use TLS has two methods to apply mutual TLS authentication, which by default verifies the validity of a remote certificate by using the/S certificate validation algorithm. The other is that exchange will go directly to check whether the server's certificate exists in AD or adlds (between the edge role and the mailbox role), which is also called direct Trust, and if the certificate exists, the certificate is valid. In this process, ad is stored as a trusted certificate.

Exchange internally automatically uses direct trust to support X-ANONYMOUSTLS and associated connections, but domain security cannot run on the front end transport service, so when outbound e-mail is routed through an Exchange 2013 Client Access server, Domain security is not supported.

How to see if a site supports TLS

Using checktls.com This site can easily query whether a site supports TLS, such as:

650) this.width=650; "title=" image "style=" border-top:0px;border-right:0px;border-bottom:0px;border-left:0px; " Border= "0" alt= "image" Src= "http://s3.51cto.com/wyfs02/M00/70/23/wKiom1WyImORnkKGAALzG35lbf0050.jpg" height= "648" />

WAN Optimization devices and TLS

Currently in a complex network environment, there is a device called WAN Optimization controller, that is, listen and optimize (compress) Some of the cross-network station traffic, most of these devices support both MAPI and SMTP traffic, but if the TLS encrypted traffic encountered, they have to decrypt before traffic optimization. There's an article on TechNet that tells us how to configure Exchange to support WAN optimization controllers, if you encounter them in a real-world environment, consider this: https://technet.microsoft.com/zh-CN/library/ ee633456%28v=exchg.150%29.aspx?f=255&mspperror=-2147217396

TLS let's talk about it here. In the next chapter we will talk about the queue ... The recent release of Exchange 2016, together with two projects at hand, has slowed down a lot of updates ...

This article is from the "Castamere Rainy season" blog, be sure to keep this source http://sodaxu.blog.51cto.com/8850288/1678163

Deep Exchange 2013"15 TLS Transport Layer Security