Phil Howard a écrit : > [snip] > Is it the case that 465 once was assigned as smtps and later retracted > and re-assigned differently? Or was it never official at all and the > /etc/services file you have isn't just an old one, but an unofficial > one?
As far as I know, it was never standardised. > 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)... > > There are "wrapper mode ssl" ports for a few other services. Probably > most known is https (443). it started with that. > Others include nntps (563), ldaps (636), > telnets (992), pop3s (995). And imap seems to have 2 variants ... > imaps (993) and an apparently older depricated imap4-ssl (585) (this > is in the IANA copy). So are these protocols somehow different in > that they need a wrapper mode, even though, in theory, some form of > STARTTLS could work on at least some of them? 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]). > > Personally, I think what should have been done was to create a whole > new transport protocol in peer with TCP, call it something that merges > TCP with TLS, assign it a new protocol number (like TCP has protocol 6 > and SCTP has protocol 132), and define it to function like TCP for IP, > but everything that uses it is "wrapper mode" TLS. Of course, that > would have required a lot of development at the system level to get > going, whereas wrapper mode as it is done now is just an add-on in > user space. 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).
