At Tue, 25 May 2010 16:00:36 -0400, Phil Howard <ttip...@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 <wo...@robohack.ca>
Planix, Inc. <wo...@planix.com> Secrets of the Weird <wo...@weird.com>
pgp2RPXRImcxn.pgp
Description: PGP signature
