NetPilot Internet Security has announced that several financial companies using both NetPilot and SoHoBlue products have successfully trialled new email encryption features. These new features are now available as an upgrade for all users of current NetPilot and SoHoBlue UTM units.
The new feature (or to give it it’s full technical title ‘Secure SMTP over Transport Layer Security’) has proven particularly useful in ensuring companies who wish to transmit sensitive data by email can do so easily and safely, with no complicated configuration or usability issues for individuals connected to the system. Encrypted email transmission between sites is automatically negotiated and setup between NetPilot units. Individual users do not have to do anything different, they transmit and receive their email in their standard way, for example using Microsoft Outlook without any additional software or user interaction.
The trial sites that tested the new NetPilot functionality were also impressed that there are no significant impacts for network administrators or the NetPilot units. Once the NetPilot products are upgraded with the new software upgrade, no extra configuration is required. The units automatically negotiate and setup encrypted links with peer units. Performance impacts are similar to utilising NetPilot VPN applications – something that NetPilot and SoHoBlue units undertake with ease.
Interoperability is also available with Microsoft Exchange Email Servers and Google Mail which can also use the same secure email transmission mechanisms.
How it Works – Some detail
NetPilot have adopted the Transport Layer Security (TLS) standard defined in the RFC 5246 to implement the new feature. TLS is a protocol that encrypts and delivers email securely helping prevent eavesdropping and spoofing (message forgery) between email servers. TLS is a standards-based protocol based on Secure Sockets Layer (SSL) the protocol used for NetPilot’s VPN communications as well as virtually all online financial transactions.
The TLS protocol uses cryptography to provide endpoint communications privacy over the internet. TLS is the email equivalent of HTTPS for web communications and uses Public Key Infrastructure (PKI) to encrypt messages from mail server to mail server. This encryption makes it more difficult for hackers to intercept and read messages.
Not only has TLS been standardised but it has been recognised as being both highly useful and secure by industry heavyweights such as Microsoft and Google who have both implemented TLS and has been recommended by HSBC for use by their business banking customers.
Links to Third Parties using compatible TLS Encryption
Microsoft Exchange Server 2010 and 2013 and TLS
HSBC utilising TLS for Busines Customers
How to check if the receiving Domain Email Server is actually using TLS for Email
There are a number of online checkers available. This one is nice and simple and tells you if the TLS is capable of being used (e.g. check NetPilot.com).
More Technical Information
Extracts from RFC 5246:
The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. At the lowest level, layered on top of some reliable transport protocol (e.g. TCP [TCP]), is the TLS Record Protocol. The TLS Record Protocol provides connection security that has two basic properties:
– The connection is private. Symmetric cryptography is used for data encryption (e.g. AES [AES], RC4 [SCH], etc.). The keys for this symmetric encryption are generated uniquely for each connection and are based on a secret negotiated by another protocol (such as the TLS Handshake Protocol).
– The connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g. SHA-1, etc.) are used for MAC computations. The Record Protocol can operate without a MAC, but is generally only used in this mode while another protocol is using the Record Protocol as a transport for negotiating security parameters.
The TLS Record Protocol is used for encapsulation of various higher-level protocols. One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to optionally authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. The TLS Handshake Protocol provides connection security. The negotiation of a shared secret is secure; the negotiated secret is unavailable to eavesdroppers and for any authenticated connection the secret cannot be obtained, even by an attacker who can place himself in the middle of the connection; the negotiation is reliable: no attacker can modify the negotiation.