Cyber Security Awareness Month - Day 15 - Ports 995, 465, and 993 - Secure Email

Cyber Security Awareness Month - Day 15 - Ports 995, 465, and 993 - Secure Email
Email has become a mainstay for both businesses and individuals. It seems a day does not go by that we are online checking for that ever important message from someone important to us. In the business world email is now our most important and timely form of communications. Information is passed from boss to employee – employee to boss – owner/manager to employee groups and employee to employee. Email is a way we can make sure that our message is heard and acted upon. I for one could not function even a day without my email. Email security is the process of using encryption to send messages that can only be opened and read by the intended recipient. Sending an email without encryption is much like sending a postcard through the Postal Service, it can be read by everyone who handles it on his way through the system from the sender to the receiver. Most of the email sent today is sent using standard SMTP without using encryption or authentication. This email is sent on port 25 in clear text format and is exposed to view. This means that there is a danger that the email can be intercepted and read by anyone, anywhere. Now for most of the email that I send and receive this is not really a problem. I really don’t care if anyone has my super Chocolate Chip Cookie recipe or my Super Hot Chili recipe. I am however involved in some organizations that provide FOUO (For Official Use Only) information. For this information I need to protect the data from prying eyes. So how do I do that? There are some really great client side utilities such as Secure MIME (S/MIME) or Pretty Good Privacy (PGP). These programs however require user involvement. The user has to know when and how to use the program and the recipient has to have the “Key” to unlock the encryption. This could be a problem for some of the users that can barely use their email. A perhaps better place to focus your security efforts is securing your SMTP traffic. There are a lot of good articles about securing SMTP traffic and the basics are the same whether you are using Linux mail programs or Microsoft Exchange or Novell Groupwise. However, each of them has their own little caveats. With the sending of secure email comes the receiving of secure email as well. One method used to accomplish this is Secure POP3 (POP3S) and Secure SMTP (SMTPS). Again there are probably as many ways to accomplish this as there are people using it. I am going to look at one way and some of our readers may have some suggestions for others. POP3S over SSL is one method utilized. Let me preface this discussion with the fact that there are some known vulnerabilities with OPEN SSL so please make sure that you apply patches or fixes as recommended by your OS manufacturer http://openssl.org/news/vulnerabilities.html. With that said, one of the methods that we have utilized is using POP3 over SSL. This a free, open source implementation of Secure Socket Layers (SSL) the same encryption layer that is used for standard, secure Internet based secure e-commerce transactions. This method uses port 995 for POP3-over-SSL and port 465 for SMTP-over-SSL and for those using IMAP it uses port 993 for IMAP-over-SSL communication. One of the key things that we did is use stunnel to create a secure channel for all of the POP3 data to be exchanged. This stunnel requires a piece of data called a Certificate be generated. This certificate is then used to validate and exchange information from device to device. These certificates can be purchased from providers such as GoDaddy or Thawte or they can be self generated. Once the certificates are in place the email passed through the ports are encrypted and validated end to end using the key. This is a very brief explanation of what Ports 995, 465 and 993 are used for. These three ports can take you from a postcard environment to a secured envelope environment with just a bit of effort. Deb Hale Long Lines, LLC	Deborah 278 Posts ISC Handler
Reply Subscribe	Oct 15th 2009 9 years ago
I tend to prefer IMAP over POP as it seems to work better for devices (like phones) where you have a slower data connection. I have sometimes had trouble configuring IMAP with SSL on these things - as best as I can tell, they don't really test this combination very much as basic POP. I look forward to the day that SMTP servers that don't require authentication/encryption are turned off by default. But I don't expect this day to come anytime soon...	Eric 43 Posts
Reply Quote	Oct 15th 2009 9 years ago
Everything sounds fine for server > client but what about all of the server > server traffic?	Chris 1 Posts
Reply Quote	Oct 16th 2009 9 years ago
Part of the problem with server > server is that most admins don't really get the concept of certificates. The Unix box that hosts my domain has a certificate that I used to connect to my email, but it is just a self-signed certificate and it is expired (if I bug them they will just generate another self-signed certificate), but that's still pretty useless. To be really useful, the certificates need to be signed by a signing authority, and the certification path needs to be traceable back to a certificate in the "trusted root certification authorities". But to get such a certificate oftentimes involves some paperwork and fighting with a bureaucracy, and oftentimes paying a fee. If you go to Verisign, Thawte, etc, you would get such a certificate. The code signing certificate that we use at the office was a royal pain to get because they need you to prove who you say you are before they will give you such a thing (otherwise I could call up and try and get a code-signing certificate for Microsoft, for example). Most admins and for that matter most organizations just don't get the need for this. Well, I guess if the organization is using https: for anything, they essentially had to go down this road at some point or another. I don't recall whether you can use the same certificate for secure smtp as you would use for https. Certificates can be marked as being for valid only for specific purposes. An email signing certificate might not be usable for code-signing, for example. Finally, lots developers don't get the advantages of using code-signing certificates to sign their binaries. If nothing else, you can scan for binaries on the system where the signature no longer matches the binary to try and find virus infected files.	Eric 43 Posts
Reply Quote	Oct 16th 2009 9 years ago
Self-signed and even expired certs are not really useless. They are perfectly fine for getting an encrypted session up, which is most of what you care about for mail. If you know that your provider uses a particular self-signed expired cert, the risk of trusting that cert based on that knowledge is much simpler and less than the risk of trusting a cert that you've never seen before based on a chain of signatures based in a trusted root certificate. Who your trusted roots are is entirely up to you and for many people, a direct provider is more trustworthy than Verisign or any of the many other entities that have manage to get their root CA certs into widely-used bundles. Encryption for mail transport between servers generally is deployed in an "opportunistic" mode that doesn't demand certificate verification, but will use whatever certificate each side has to set up encryption, protecting from 3rd-party snooping of traffic but not preventing a man-in-the-middle attack. Note that for most cases of server to server transport, MITM attacks are impossible to prevent purely with certificate verification, because both sides only know who the transport partner should be based on DNS, which has its own complex of insecurities, and ultimately a certificate only can identify the partner as the rightful user of a DNS name, it can't say whether the owner of that domain name is good or evil, competent or careless. The same sorts of issues, sometimes referred to as a distinction between authentication and authorization, exist for the use of certificates for code signing. A valid code signature only means that the code is what its author signed, it does not mean that the code or its author are trustworthy. As for using the same certificate for multiple purposes, that is entirely a function of how the issuer sets key usage and certificate type flags in a certificate. All SSL/TLS uses are covered by the same flags, so a certificate that works for HTTPS by a server can also be used by that server (or any server with a name matching one of the alternate names in the cert) for SSL/TLS wrapping of any other protocol. Typically a commercial issuer will not enable a SSL/TLS server cert for other uses like code signing.	Anonymous
Reply Quote	Oct 16th 2009 9 years ago
Using dedicated ports for any protocol over SSL is an archaic practice that should not be encouraged. That approach has been on the way out for over a decade because it was recognized as unscalable during the process of turning Netscape's proposal for SSL 3.0 into the real open standard of TLS 1.0. With that evolution came the shift to step-up mechanisms that negotiate encryption after initial connection, on the same TCP port used by the generic protocol. POP, IMAP, and SMTP all have had such standardized mechanisms for many years, and they are supported by all modern mail servers and clients: the commands STLS in POP3 and STARTTLS for IMAP4 and SMTP. In particular, using TCP port 465 for "SMTPS" never was any sort of formal standard and is NOT something anyone should deploy today if they aren't already stuck with it. Netscape and MS implemented that usage and it appeared in Netscape's 1996 SSL 3.0 draft but wisely, IANA never was asked to allocate 465 for SMTPS, and eventually assigned 465 to a completely different protocol. Using 993 and 995 for POP and IMAP over SSL are a bit less bad (at least they are registered ports) but doing so is still problematic. SSL is a dead protocol in that it was superseded by TLS in 1999. That leaves dedicated-port SSL implementations in a bad place, since no TLS specification defines that sort of implementation. TLS is continuing to advance (TLS 1.1 was defined in 2006) but dedicated-port implementations have to stick with SSL 3.0 if they want to follow a defined standard. Thus, POP3S, IMAPS, and SMTPS (ports 995, 993, and 465) are permanently stuck with the (admittedly small) vulnerabilities in SSL 3.0 that TLS 1.1 fixes. Over time there could be worse issues discovered in SSL 3.0 that will never be repaired, while TLS specs and their implementations will be able to adapt. One other thing that is missing from this diary entry is discussion of port 587, which is assigned to the "SUBMIT" protocol. SUBMIT is a variant of SMTP, deployed on port 587 with a set of extensions and administrative norms as defined by RFC's 2476 and 4409. Essentially all modern mail software supports SUBMIT, and anyone who needs to provide initial message submission service to users should be deploying SUBMIT with TLS and authentication required. Supporting user submission of mail via traditional SMTP on port 25 (or SMTPS on 465) is an accommodation to historical practice that is increasingly obsolete. Using SMTP for both initial submission and transport was always a bit of a kludge relative to email security, and deploying SUBMIT securely allows one to resolve the conflicts between the best policies and practices for submission and for transport.	Anonymous
Reply Quote	Oct 16th 2009 9 years ago
If you use gmail, it's worth noting that by connecting on https://gmail.com your whole gmail session including the login will be encrypted. Some other well known sites let you connect and login on https:// also. Examples: https://twitter.com https://facebook.com However, facebook reverts to plain old http:// after login	Anonymous
Reply Quote	Oct 16th 2009 9 years ago

Email has become a mainstay for both businesses and individuals. It seems a day does not go by that we are online checking for that ever important message from someone important to us. In the business world email is now our most important and timely form of communications. Information is passed from boss to employee – employee to boss –
owner/manager to employee groups and employee to employee. Email is a way we can make sure that our message is heard and acted upon. I for one could not function even a day without my email.

Email security is the process of using encryption to send messages that can only be opened and read by the intended recipient. Sending an email without encryption is much like sending a postcard through the Postal Service, it can be read by everyone who handles it on his way through the system from the sender to the receiver.

Most of the email sent today is sent using standard SMTP without using encryption or authentication. This email is sent on port 25 in clear text format and is exposed to view. This means that there is a danger that the email can be intercepted and read by anyone, anywhere. Now for most of the email that I send and receive this is not really a problem. I really don’t care if anyone has my super Chocolate Chip Cookie recipe or my Super Hot Chili recipe. I am however involved in some organizations that provide FOUO (For Official Use Only) information. For this information I need to protect the data from prying eyes. So how do I do that?

There are some really great client side utilities such as Secure MIME (S/MIME) or Pretty Good Privacy (PGP). These programs however require user involvement. The user has to know when and how to use the program and the recipient has to have the “Key” to unlock the encryption. This could be a problem for some of the users that can barely use their email.

A perhaps better place to focus your security efforts is securing your SMTP traffic. There are a lot of good articles about securing SMTP traffic and the basics are the same whether you are using Linux mail programs or Microsoft Exchange or Novell Groupwise. However, each of them has their own little caveats.

With the sending of secure email comes the receiving of secure email as well. One method used to accomplish this is Secure POP3 (POP3S) and Secure SMTP (SMTPS). Again there are probably as many ways to accomplish this as there are people using it. I am going to look at one way and some of our readers may have some suggestions for others.

POP3S over SSL is one method utilized. Let me preface this discussion with the fact that there are some known vulnerabilities with OPEN SSL so please make sure that you apply patches or fixes as recommended by your OS manufacturer http://openssl.org/news/vulnerabilities.html. With that said, one of the methods that we have utilized is using POP3 over SSL. This a free, open source implementation of Secure Socket Layers (SSL) the same encryption layer that is used for standard, secure Internet based secure e-commerce transactions. This method uses port 995 for POP3-over-SSL and port 465 for SMTP-over-SSL and for those using IMAP it uses port 993 for IMAP-over-SSL communication.

One of the key things that we did is use stunnel to create a secure channel for all of the POP3 data to be exchanged. This stunnel requires a piece of data called a Certificate be generated. This certificate is then used to validate and exchange information from device to device. These certificates can be purchased from providers such as GoDaddy or Thawte
or they can be self generated. Once the certificates are in place the email passed through the ports are encrypted and validated end to end using the key.

This is a very brief explanation of what Ports 995, 465 and 993 are used for. These three ports can take you from a postcard environment to a secured envelope environment with just a bit of effort.

Deb Hale Long Lines, LLC

Deborah

278 Posts
ISC Handler

I tend to prefer IMAP over POP as it seems to work better for devices (like phones) where you have a slower data connection. I have sometimes had trouble configuring IMAP with SSL on these things - as best as I can tell, they don't really test this combination very much as basic POP.

I look forward to the day that SMTP servers that don't require authentication/encryption are turned off by default. But I don't expect this day to come anytime soon...

Eric

43 Posts

Everything sounds fine for server > client but what about all of the server > server traffic?

Chris

1 Posts

Part of the problem with server > server is that most admins don't really get the concept of certificates. The Unix box that hosts my domain has a certificate that I used to connect to my email, but it is just a self-signed certificate and it is expired (if I bug them they will just generate another self-signed certificate), but that's still pretty useless.

To be *really* useful, the certificates need to be signed by a signing authority, and the certification path needs to be traceable back to a certificate in the "trusted root certification authorities". But to get such a certificate oftentimes involves some paperwork and fighting with a bureaucracy, and oftentimes paying a fee. If you go to Verisign, Thawte, etc, you would get such a certificate. The code signing certificate that we use at the office was a royal pain to get because they need you to prove who you say you are before they will give you such a thing (otherwise I could call up and try and get a code-signing certificate for Microsoft, for example).

Most admins and for that matter most organizations just don't get the need for this. Well, I guess if the organization is using https: for anything, they essentially *had* to go down this road at some point or another.

I don't recall whether you can use the same certificate for secure smtp as you would use for https. Certificates can be marked as being for valid only for specific purposes. An email signing certificate might not be usable for code-signing, for example.

Finally, lots developers don't get the advantages of using code-signing certificates to sign their binaries. If nothing else, you can scan for binaries on the system where the signature no longer matches the binary to try and find virus infected files.

Eric

43 Posts

Self-signed and even expired certs are not really useless. They are perfectly fine for getting an encrypted session up, which is most of what you care about for mail. If you know that your provider uses a particular self-signed expired cert, the risk of trusting that cert based on that knowledge is much simpler and less than the risk of trusting a cert that you've never seen before based on a chain of signatures based in a trusted root certificate. Who *your* trusted roots are is entirely up to *you* and for many people, a direct provider is more trustworthy than Verisign or any of the many other entities that have manage to get their root CA certs into widely-used bundles.

Encryption for mail transport between servers generally is deployed in an "opportunistic" mode that doesn't demand certificate verification, but will use whatever certificate each side has to set up encryption, protecting from 3rd-party snooping of traffic but not preventing a man-in-the-middle attack. Note that for most cases of server to server transport, MITM attacks are impossible to prevent purely with certificate verification, because both sides only know who the transport partner should be based on DNS, which has its own complex of insecurities, and ultimately a certificate only can identify the partner as the rightful user of a DNS name, it can't say whether the owner of that domain name is good or evil, competent or careless. The same sorts of issues, sometimes referred to as a distinction between authentication and authorization, exist for the use of certificates for code signing. A valid code signature only means that the code is what its author signed, it does not mean that the code or its author are trustworthy.

As for using the same certificate for multiple purposes, that is entirely a function of how the issuer sets key usage and certificate type flags in a certificate. All SSL/TLS uses are covered by the same flags, so a certificate that works for HTTPS by a server can also be used by that server (or any server with a name matching one of the alternate names in the cert) for SSL/TLS wrapping of any other protocol. Typically a commercial issuer will not enable a SSL/TLS server cert for other uses like code signing.

Anonymous

Using dedicated ports for any protocol over SSL is an archaic practice that should not be encouraged. That approach has been on the way out for over a decade because it was recognized as unscalable during the process of turning Netscape's proposal for SSL 3.0 into the real open standard of TLS 1.0. With that evolution came the shift to step-up mechanisms that negotiate encryption after initial connection, on the same TCP port used by the generic protocol. POP, IMAP, and SMTP all have had such standardized mechanisms for many years, and they are supported by all modern mail servers and clients: the commands STLS in POP3 and STARTTLS for IMAP4 and SMTP.

In particular, using TCP port 465 for "SMTPS" never was any sort of formal standard and is NOT something anyone should deploy today if they aren't already stuck with it. Netscape and MS implemented that usage and it appeared in Netscape's 1996 SSL 3.0 draft but wisely, IANA never was asked to allocate 465 for SMTPS, and eventually assigned 465 to a completely different protocol. Using 993 and 995 for POP and IMAP over SSL are a bit less bad (at least they are registered ports) but doing so is still problematic. SSL is a dead protocol in that it was superseded by TLS in 1999. That leaves dedicated-port SSL implementations in a bad place, since no TLS specification defines that sort of implementation. TLS is continuing to advance (TLS 1.1 was defined in 2006) but dedicated-port implementations have to stick with SSL 3.0 if they want to follow a defined standard. Thus, POP3S, IMAPS, and SMTPS (ports 995, 993, and 465) are permanently stuck with the (admittedly small) vulnerabilities in SSL 3.0 that TLS 1.1 fixes. Over time there could be worse issues discovered in SSL 3.0 that will never be repaired, while TLS specs and their implementations will be able to adapt.

One other thing that is missing from this diary entry is discussion of port 587, which is assigned to the "SUBMIT" protocol. SUBMIT is a variant of SMTP, deployed on port 587 with a set of extensions and administrative norms as defined by RFC's 2476 and 4409. Essentially all modern mail software supports SUBMIT, and anyone who needs to provide initial message submission service to users should be deploying SUBMIT with TLS and authentication required. Supporting user submission of mail via traditional SMTP on port 25 (or SMTPS on 465) is an accommodation to historical practice that is increasingly obsolete. Using SMTP for both initial submission and transport was always a bit of a kludge relative to email security, and deploying SUBMIT securely allows one to resolve the conflicts between the best policies and practices for submission and for transport.

Anonymous

If you use gmail, it's worth noting that by connecting on https://gmail.com your whole gmail session including the login will be encrypted.

Some other well known sites let you connect and login on https:// also. Examples:

https://twitter.com
https://facebook.com

However, facebook reverts to plain old http:// after login :-(

Anonymous