which port to use for SSL/TLS?
in [Postfix]
|
From: "Greg A. Woods" on 27 May 2010 17:36 At Tue, 25 May 2010 16:00:36 -0400, Phil Howard <ttiphil(a)gmail.com> wrote: Subject: Re: which port to use for SSL/TLS? > > 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. This might seem odd to some for me to say, but I really don't understand why you're trying so vainly to be such a stickler for the so-called "standards" in this case. IANA's "port numbers" are more a Best Common Practice than a literal standard. You're free to provide whatever service you so wish to provide on any port you please. The published port assignments, especially those in the 0-1023 range, i.e. the Well Known Ports, are simply a guideline to help you to inter-operate with "unknown callers". If your users are all known to you then they will all know which port to use through prior arrangement. By definition one could conclude that all users of a service requiring authentication and authorization are in fact "known callers". Finally, since running SMTP through SSL was previously defined and assigned a port number, then supporting legacy applications using this protocol and port number is well within the boundaries of valid use. The only really valid reason for _not_ providing SMTP through SSL, (aka "ssmtp" or "smtps") on port 465 would be if you really had to support the newly assigned "urd" (URL Rendesvous Directory for SSM) protocol for _unknown_ callers also on port 465, and also on the exact same IP address (or perhaps through the same NAT-based firewall if for some stupid reason you've put your servers behind a NAT on some non-public IP addresses). > 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). Are you sure your soap-box is the most secure one to promote? The only real reason why SMTPS was "deprecated" was solely because of politics. There was never any technical reason to deprecate SMTPS. It was done as a result of someone having the fool-headed idea to think that since it is _possible_ to initiate TLS from within the SMTP transaction, then that should be the _only_ way to do it. Note that the original RFC 2487 even goes so far to suggest that STARTTLS is less secure than SMTPS by noting an obvious MitM attack (and suggesting only a relatively ludicrous work-around). That RFC's author gave the following contradictory excuse to IANA via e-mail in order to cause the unilateral deprecation of SMTPS: "The email community has reached rough concensus that widespread use of such a port will be harmful to the performance, interoperability and security of SMTP." Note there are even further MitM weaknesses in the original STARTTLS protocol as well, all of which are avoided entirely by SMTPS. Indeed, SMTPS threatens the success of STARTTLS because it is more secure than using STARTTLS. So, one must ask one's self if STARTTLS was truly the best option for SMTP, when why was it not so for every other protocol that could have been similarly extended from within, including HTTP, IMAP, NNTP, FTP, TELNET, IRC, and so on? The whole idea of trying to support TLS as an add-on or extension to an existing protocol and to do so by using an "optional" in-band request, is entirely antithetical to the ideal of using TLS to protect the _entire_ encapsulated protocol. Finally remember that the deprecation of SMTPS was never done officially or via any published standard. It was done simply by fiat when Paul Hoffman asked IANA on his own to deprecate SMTPS prior to the final publication of his STARTTLS RFC 2487. The language suggesting the deprecation of SMTPS and reassignment of port 465 was then removed from the STARTTLS draft and there was no opportunity for further discussion through the RFC process. Politics. -- Greg A. Woods +1 416 218-0098 VE3TCP RoboHack <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com> Secrets of the Weird <woods(a)weird.com>
From: Phil Howard on 28 May 2010 11:56 On Thu, May 27, 2010 at 17:36, Greg A. Woods <woods(a)planix.com> wrote: > This might seem odd to some for me to say, but I really don't understand > why you're trying so vainly to be such a stickler for the so-called > "standards" in this case. > > IANA's "port numbers" are more a Best Common Practice than a literal > standard. You're free to provide whatever service you so wish to > provide on any port you please. The published port assignments, > especially those in the 0-1023 range, i.e. the Well Known Ports, are > simply a guideline to help you to inter-operate with "unknown callers". > If your users are all known to you then they will all know which port to > use through prior arrangement. By definition one could conclude that > all users of a service requiring authentication and authorization are in > fact "known callers". But it's more than just BCP for me (or you). It's a knowledge of BCP for others as that might impact me (or you). For example, it means it is unlikely that a reputable manufacturer will implement or deploy (MSFT doesn't fit that for me). > Finally, since running SMTP through SSL was previously defined and > assigned a port number, then supporting legacy applications using this > protocol and port number is well within the boundaries of valid use. That can justify it ... on a "phasing it out" basis. I did actually turn 465 on to see if it worked. It did. Then I commented it out. So I have "phased it out". > The only really valid reason for _not_ providing SMTP through SSL, (aka > "ssmtp" or "smtps") on port 465 would be if you really had to support > the newly assigned "urd" (URL Rendesvous Directory for SSM) protocol for > _unknown_ callers also on port 465, and also on the exact same IP > address (or perhaps through the same NAT-based firewall if for some > stupid reason you've put your servers behind a NAT on some non-public IP > addresses). I disagree. If port 465 becomes regularly used for a non-standard purpose, people will begin to use it and expect it to be there. If later on (for example a few years later), the official use for port 465 (urd) needs to be deployed, then a conflict suddenly exists. And it might not be noticed in the planning phase because it might be different teams using these things. It may become necessary to abruptly shut off SMTPS on port 465 because of that (if there's no easy way to make these different services coexist, which is not a known certainty ahead of time). >> 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). > > Are you sure your soap-box is the most secure one to promote? I'm not on a soap box. It has been for a long term practice (for me) to stick with standards unless I have a compelling need to deviate (and believe me, I have many times needed to do that). At this time, there is no specific need for SMTPS that cannot be filled by {SMTP|Submission}+STARTTLS on 25|587 ... so ... at this time, there is no compelling need for SMTPS that would have me consider how to "go beyond" the standards. If it were a standard port, I would have fired it up just to see if it needed to be used. What I did instead is configured it as commented out, and will address any complaints when/if they arrive (none to date ... 2 days into activation). > The only real reason why SMTPS was "deprecated" was solely because of > politics. There was never any technical reason to deprecate SMTPS. It > was done as a result of someone having the fool-headed idea to think > that since it is _possible_ to initiate TLS from within the SMTP > transaction, then that should be the _only_ way to do it. I'm not disagreeing with this. I think there should be an SMTPS. > Note that the original RFC 2487 even goes so far to suggest that > STARTTLS is less secure than SMTPS by noting an obvious MitM attack (and > suggesting only a relatively ludicrous work-around). That RFC's author > gave the following contradictory excuse to IANA via e-mail in order to > cause the unilateral deprecation of SMTPS: "The email community has > reached rough concensus that widespread use of such a port will be > harmful to the performance, interoperability and security of SMTP." Correct me if I am wrong (as I have heard this only 2nd hand), but my understanding is that the intended use of SMTPS included MX purposes (albeit wrapped in TLS). > Note there are even further MitM weaknesses in the original STARTTLS > protocol as well, all of which are avoided entirely by SMTPS. > Indeed, SMTPS threatens the success of STARTTLS because it is more > secure than using STARTTLS. I don't disagree. If you need more people to champion the cause to bring back SMTPS, let me know. > So, one must ask one's self if STARTTLS was truly the best option for > SMTP, when why was it not so for every other protocol that could have > been similarly extended from within, including HTTP, IMAP, NNTP, FTP, > TELNET, IRC, and so on? The whole idea of trying to support TLS as an > add-on or extension to an existing protocol and to do so by using an > "optional" in-band request, is entirely antithetical to the ideal of > using TLS to protect the _entire_ encapsulated protocol. Perhaps (I'm speculating), the nature of the protocols (including a _narrow_ view of SMTP) as seen by some suggested that SMTP didn't need the level of authentication the others did. I don't agree, but just trying to see how the process might have come to the conclusion it did. I was never involved in that process, even as an observer (I wish I had been). > Finally remember that the deprecation of SMTPS was never done officially > or via any published standard. It was done simply by fiat when Paul > Hoffman asked IANA on his own to deprecate SMTPS prior to the final > publication of his STARTTLS RFC 2487. The language suggesting the > deprecation of SMTPS and reassignment of port 465 was then removed from > the STARTTLS draft and there was no opportunity for further discussion > through the RFC process. There are a number of unassigned ports still in the range less than 1024. Do you feel it is worth the cause to bring back SMTPS at least on another port number? I'm curious why it is that port 465 got assigned to another service rather than one of the still unassigned ports? FYI, I do run SSH on various unassigned ports. That's because I don't want the log floods I'd get if I had SSH facing the wild on port 22 (I've had on a couple days over a million dictionary attempts to root, all unsuccessful, but occupying 99% of the log file space). > Politics. Yes. And I hate it. But I have to live with it and work around it.
From: Victor Duchovni on 28 May 2010 14:24 On Fri, May 28, 2010 at 11:56:15AM -0400, Phil Howard wrote: > I'm not disagreeing with this. I think there should be an SMTPS. Rhetorical question: How would a sending domain know that a particular receiving domain supports SMTPS? Clearly SMTPS would not be an alternative to SMTP for MX hosts, rather it is only alternative to to port 587+STARTTLS for submission servers. This means that if we want to support (opportunistic) TLS for domain to domain delivery, we need STARTTLS. And in fact opportunistic TLS is now widely (though not universally) deployed in this context. Given that SMTP + STARTTLS is available, there is little need for yet another protocol for submission. So on the whole SMTPS would not solve any issues that SMTP + STARTTLS does not handle adequately. Over and out. -- 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: Phil Howard on 28 May 2010 14:35 On Fri, May 28, 2010 at 14:24, Victor Duchovni <Victor.Duchovni(a)morganstanley.com> wrote: > On Fri, May 28, 2010 at 11:56:15AM -0400, Phil Howard wrote: > >> I'm not disagreeing with this. I think there should be an SMTPS. > > Rhetorical question: How would a sending domain know that a particular > receiving domain supports SMTPS? Try it an see. If it fails to connect or times out, and local policy and/or message parameters allow this, fall back to SMTP. Specific detail are probably subject to discussion and maybe standardization. > Clearly SMTPS would not be an alternative to SMTP for MX hosts, rather > it is only alternative to to port 587+STARTTLS for submission servers. I don't agree. But it could be argued that SMTP+STARTTLS is sufficient for MX. I haven't done the analysis to know if the exposure risks in STARTTLS apply to MX or not. > This means that if we want to support (opportunistic) TLS for domain > to domain delivery, we need STARTTLS. And in fact opportunistic TLS > is now widely (though not universally) deployed in this context. And this goes back to the arguments for SMTPS. Is there any definitive analysis that says that STARTTLS has risks for submission and never can have any for MX? > Given that SMTP + STARTTLS is available, there is little need for yet > another protocol for submission. So on the whole SMTPS would not solve > any issues that SMTP + STARTTLS does not handle adequately. Over and > out. I guess you need to argue that with Greg. He seems to be more of an advocate for that than I do (I don't have the time to do the analysis .... though I do have the biased preference to simply move EVERYTHING on TCP ... and even SCTP ... over to wrapped TLS).
From: Victor Duchovni on 28 May 2010 14:46
On Fri, May 28, 2010 at 02:35:13PM -0400, Phil Howard wrote: > On Fri, May 28, 2010 at 14:24, Victor Duchovni > <Victor.Duchovni(a)morganstanley.com> wrote: > > On Fri, May 28, 2010 at 11:56:15AM -0400, Phil Howard wrote: > > > >> I'm not disagreeing with this. ?I think there should be an SMTPS. > > > > Rhetorical question: How would a sending domain know that a particular > > receiving domain supports SMTPS? > > Try it an see. If it fails to connect or times out, and local policy > and/or message parameters allow this, fall back to SMTP. Specific > detail are probably subject to discussion and maybe standardization. No. This is a really poor idea. You're not supposed to answer rhetorical questions, you just risk looking a bit silly... > > Clearly SMTPS would not be an alternative to SMTP for MX hosts, rather > > it is only alternative to to port 587+STARTTLS for submission servers. > > I don't agree. But it could be argued that SMTP+STARTTLS is > sufficient for MX. I haven't done the analysis to know if the > exposure risks in STARTTLS apply to MX or not. See above. > And this goes back to the arguments for SMTPS. Is there any > definitive analysis that says that STARTTLS has risks for submission > and never can have any for MX? There is no fundamental need for a second protocol, but Postfix supports it because legacy clients (that will over the next few years disappear, since modern Outlook supports STARTTLS) don't support 587 + STARTTLS. > I guess you need to argue that with Greg. He seems to be more of an > advocate for that than I do (I don't have the time to do the analysis > ... though I do have the biased preference to simply move EVERYTHING > on TCP ... and even SCTP ... over to wrapped TLS). I don't get into arguments with Greg. -- Viktor. |