which port to use for SSL/TLS?
in [Postfix]
|
From: Phil Howard on 25 May 2010 09:09 On Mon, May 24, 2010 at 18:14, mouss <mouss(a)ml.netoyen.net> wrote: > As far as I know, it was never standardised. Good enough reason for me to not use it. >> I get mine from IANA and 465 is assigned differently. > > what OS do you run? if smtps != 465 on your system, then the default > master.cf doesn't work for you, which means you have an odd system (and > not the opposite)... Several. The current project is on Ubuntu 9.10. I may move it to Slackware 13.1. Nothing odd about these or any others I have used. I do update and upgrade where practical. I'm finding that with Ubuntu that's not always so, beyond what they pre-package. But for the /etc/services file, that's never been a problem to regularly get the official one from IANA, which I have been doing for a couple decades. > wrapper mode SSL != STARTTLS. the former means the SSL/TLS negociation > happens before anything else. This provides more "confidentiality" (with > https, a sniffer doesn't know where you're trying to go), but it also > creates problems (for example, you currently need one IP per https > server [until the extensions to workaround this are widely implemented]). Even with STARTTLS (or STLS, or A STARTTLS, or whatever is used for some protocol), you still need one IP per hostname identified certificate, unless you have some means to select the host in advance that is safe to do (not sure if that is possible). > STARTTLS is enough, if you want control at app level. if you don't, then > use IPSec. There is no need to invent useless protocols (the more > protocols we have, the more opportunity for incompatibility, bugs, > vulnearbilities, ... etc). It is hard for firewall level controls to force encryption, unless it is known that a given port always does. So from that perspective, wrapper mode TLS/SSL is easier, when using standard ports for that. You (in the role of firewall admin) can, for example, allow port 443 and disallow port 80 to ensure everyone is using encryption. In the case of ports using STARTTLS or the like, you need to do sniff into the TCP stream layer and see if STARTTLS is really being done (or be the server admin and force it there).
From: Victor Duchovni on 25 May 2010 11:59 On Tue, May 25, 2010 at 09:09:09AM -0400, Phil Howard wrote: > On Mon, May 24, 2010 at 18:14, mouss <mouss(a)ml.netoyen.net> wrote: > > As far as I know, it was never standardised. > > Good enough reason for me to not use it. This is the de-facto standard port for the service. Shoot yourself in the foot if you wish, but for the record anyone implementing SMTP over SSL (rather STARTTLS over SMTP) should use port 465 for that service. -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
From: Kris Deugau on 25 May 2010 13:41 Victor Duchovni wrote: > On Tue, May 25, 2010 at 09:09:09AM -0400, Phil Howard wrote: > >> On Mon, May 24, 2010 at 18:14, mouss <mouss(a)ml.netoyen.net> wrote: >>> As far as I know, it was never standardised. >> Good enough reason for me to not use it. > > This is the de-facto standard port for the service. Shoot yourself in > the foot if you wish, but for the record anyone implementing SMTP over > SSL (rather STARTTLS over SMTP) should use port 465 for that service. Not to mention the fact that, IIRC, old versions of Outlook (and possibly Outlook Express) that support SMTP over SSL *hardcode* port 465 - or at least bury any option to change it somewhere most people will never find it. If you must support those clients, you must use that port. -kgd
From: Phil Howard on 25 May 2010 16:00 On Tue, May 25, 2010 at 13:41, Kris Deugau <kdeugau(a)vianet.ca> wrote: > Victor Duchovni wrote: >> >> On Tue, May 25, 2010 at 09:09:09AM -0400, Phil Howard wrote: >> >>> On Mon, May 24, 2010 at 18:14, mouss <mouss(a)ml.netoyen.net> wrote: >>>> >>>> As far as I know, it was never standardised. >>> >>> Good enough reason for me to not use it. >> >> This is the de-facto standard port for the service. Shoot yourself in >> the foot if you wish, but for the record anyone implementing SMTP over >> SSL (rather STARTTLS over SMTP) should use port 465 for that service. > > Not to mention the fact that, IIRC, old versions of Outlook (and possibly > Outlook Express) that support SMTP over SSL *hardcode* port 465 - or at > least bury any option to change it somewhere most people will never find it. > If you must support those clients, you must use that port. At this point I'm just not going to support SMTP wrapped/tunneled over SSL/TLS ... on any port. But just in case something comes up where I have to support it, I do have the config for it in comments with port 465. They won't get that until after they've heard "show me the RFC" and "Microsoft doesn't follow real standards" a couple times. But IMAP and POP are enabled on a wrapped/tunneled SSL/TLS port (993 and 995), since a standard does exist (but I'm not telling anyone but the other admin about it ... I'm promoting STARTTLS/STLS for everything).
From: mouss on 25 May 2010 19:02
Phil Howard a �crit : > On Mon, May 24, 2010 at 18:14, mouss <mouss(a)ml.netoyen.net> wrote: >> As far as I know, it was never standardised. > > Good enough reason for me to not use it. > if you don't need it, then you don't need it:) - if you have customers with old outlook, then you'd better offer smtps (465) than force them to use "clear text" access. after all, smtps works (and enabling this in postfix is a no brainer). - sometimes, relays offer smtps as the only SSL implementation. Last time I checked, that's a long time ago, this was (is?) the case at my hoster (ovh). I don't care much, but I am not happy to send the mail without SSL, given that customers hosted in the same network can sniff my traffic. I don't send'em mail. but if I had to, I would use stunnel to send them mail via smtps rather than plain text. >>> I get mine from IANA and 465 is assigned differently. >> what OS do you run? if smtps != 465 on your system, then the default >> master.cf doesn't work for you, which means you have an odd system (and >> not the opposite)... > > Several. The current project is on Ubuntu 9.10. hmmm. you modified your /etc/services... $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=9.10 DISTRIB_CODENAME=karmic DISTRIB_DESCRIPTION="Ubuntu 9.10 $ grep smtps /etc/services ssmtp 465/tcp smtps # SMTP over SSL similar results on other systems. > I may move it to > Slackware 13.1. Nothing odd about these or any others I have used. I > do update and upgrade where practical. I'm finding that with Ubuntu > that's not always so, beyond what they pre-package. But for the > /etc/services file, that's never been a problem to regularly get the > official one from IANA, which I have been doing for a couple decades. > remember that /etc/services is nothing more than a database. it better have more entries than too few. but this is off topic here... said otherwise, /etc/services has nothing to do with IANA. (IANA is about "to avoid this port number being used by someone else, reserve. /etc/services is about giving a name for a port number, be it IANA reserved, de facto standard or local). > >> wrapper mode SSL != STARTTLS. the former means the SSL/TLS negociation >> happens before anything else. This provides more "confidentiality" (with >> https, a sniffer doesn't know where you're trying to go), but it also >> creates problems (for example, you currently need one IP per https >> server [until the extensions to workaround this are widely implemented]). > > Even with STARTTLS (or STLS, or A STARTTLS, or whatever is used for > some protocol), you still need one IP per hostname identified > certificate, unless you have some means to select the host in advance > that is safe to do (not sure if that is possible). > I can write a proxy that passes connections to different smtp servers (with different certificates and configs) based on client IP/helo/ehlo. and I can write a client that uses different certificates based on the smtpd banner. I can't do that for HTTPs (well, there's still the nego afterwards, but it's not yet "reliable"...). > >> STARTTLS is enough, if you want control at app level. if you don't, then >> use IPSec. There is no need to invent useless protocols (the more >> protocols we have, the more opportunity for incompatibility, bugs, >> vulnearbilities, ... etc). > > It is hard for firewall level controls to force encryption, unless it > is known that a given port always does. been there... network firewalls should do network firewalling. if you want more, use an application firewall or a proxy. to force encryption, do it at the application side. if not possible, use a proxy. trying to enforce encryption using a network firewall will fail. (A long time ago, I worked for a security vendor. I spent some time working on firewalling, VPN, authentication, ... etc. at that time, I looked at this from down, up, right, left, front and behind, and the result was always the same: use the right tool). > So from that perspective, > wrapper mode TLS/SSL is easier, when using standard ports for that. > You (in the role of firewall admin) can, for example, allow port 443 > and disallow port 80 to ensure everyone is using encryption. In the > case of ports using STARTTLS or the like, you need to do sniff into > the TCP stream layer and see if STARTTLS is really being done (or be > the server admin and force it there). if you have control over the application, it doesn't matter what port is open. if you don't control the application, it doesn't matter either. the thing is: the (network) firewall can't enforce anything at the application level. one can pass unauthorized traffic via port 80 (don't tell me: "my proxy detects tunnelling". it will only detect "stupid" tunnelling). |