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 –
|
Deborah 278 Posts ISC Handler |
Subscribe |
Oct 15th 2009 1 decade 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 |
Quote |
Oct 15th 2009 1 decade ago |
Everything sounds fine for server > client but what about all of the server > server traffic?
|
Chris 1 Posts |
Quote |
Oct 16th 2009 1 decade 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 |
Quote |
Oct 16th 2009 1 decade 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 |
Quote |
Oct 16th 2009 1 decade 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 |
Quote |
Oct 16th 2009 1 decade 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 |
Quote |
Oct 16th 2009 1 decade ago |
Sign Up for Free or Log In to start participating in the conversation!