https://www.fastmail.fm/help/technology_ssl_vs_tls_starttls.html
SSL vs TLS vs STARTTLS
There's often quite a bit of confusion about the different terms SSL vs TLS vs STARTTLS.
- SSL and TLS both provide a way to encrypt a communication channel between two computers (e.g. your computer and our server). TLS is the successor to SSL and the terms SSL and TLS are used interchangeably unless you're referring to a specific version of the protocol.
- STARTTLS is a way to take an existing insecure connection, and upgrade it to a secure connection using SSL/TLS. Note that despite having TLS in the name, STARTTLS doesn't mean you have to use TLS, you can use SSL.
Version numbering is inconsistent between SSL and TLS versions. When TLS took over SSL as the preferred protocol name, it began a new version number, and also began using sub-versions. So the ordering of protocols in terms of oldest to newest is: SSLv2, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2.
When you connect to an SSL/TLS encrypted port, or use STARTTLS to upgrade an existing connection, both sides will negotiate which protocol and which version to use based on what has been configured in the software and what each side supports.
Support for SSL/TLS is virtually universal these days, however which versions are supported is variable. Pretty much everything supports SSLv3 (except a few very old Palm Treo devices as we discovered). Most things support TLSv1.0. As at May 2012, support for TLSv1.1 and TLSv1.2 is more limited.
One significant complicating factor is that some email software incorrectly uses the term TLS when they should have used STARTTLS. Older versions of Thunderbird in particular used "TLS" to mean "enforce use of STARTTLS to upgrade the connection, and fail if STARTTLS is not supported" and "TLS, if available" to mean "use STARTTLS to upgrade the connection if the server advertises support for it, otherwise just use an insecure connection".
The above is particularly problematic when combined with having to configure a port number for each protocol.
To add security to some existing protocols (eg IMAP, POP, etc), it was decided to just add SSL/TLS encryption as a layer underneath the existing protocol. However to distinguish that software should talk the SSL/TLS encrypted version of the protocol rather than the plaintext one, a different port number was used for each protocol. So you have:
- IMAP uses port 143, but SSL/TLS encrypted IMAP uses port 993
- POP uses port 110, but SSL/TLS encrypted POP uses port 995
- SMTP uses port 25, but SSL/TLS encrypted SMTP uses port 465
At some point, it was decided that having 2 ports for every protocol was wasteful, and instead you should have 1 port that starts off as plaintext, but the client can upgrade the connection to an SSL/TLS encrypted one. This is what STARTTLS was created to do.
There were a few problems with this though. There was already existing software that used the alternate port numbers with pure SSL/TLS connections. Client software can be very long lived, so you can't just disable the encrypted ports until all software has been upgraded.
Mechanisms were added to each protocol to tell clients that the plaintext protocol supported upgrading to SSL/TLS (e.g. STARTTLS), and that they should not attempt to login without doing the STARTTLS upgrade. This created two unfortunate situations:
- Some software just ignored the "login disabled until upgraded" announcement and just tried to log in anyway, sending the user login name and password over plaintext. Even if the server then rejected the login, the details had already been sent over the Internet in plaintext.
- Other software saw the "login disabled until upgraded" announcement, but then wouldn't upgrade the connection automatically, and thus reported login errors back to the user, which caused confusion about what was wrong.
Both of these problems resulted in significant compatibility issues with existing clients, and so most system administrators continued to just use plaintext connections on one port number, and encrypted connections on a separate port number.
This has now basically become the defacto standard that everyone uses. IMAP SSL/TLS encrypted over port 993 or POP SSL/TLS encrypted over port 995. Many sites are now disabling plain IMAP (port 143) and plain POP (port 110) altogether so people must use a SSL/TLS encrypted connection. By disabling ports 143 and 110, this removes completely STARTTLS as even an option for IMAP/POP connections.
The one real exception to the above is SMTP. However that's for a different reason again. Most email software used SMTP on port 25 to submit messages to the email server for onward transmission to the destination. However SMTP was originally designed for transfer, not submission. So yet another port (587) was defined for message submission. Although port 587 doesn't mandate requiring STARTTLS, the use of port 587 became popular around the same time as the realisation that SSL/TLS encryption of communications between clients and servers was an important security and privacy issue.
The result is that in most cases, systems that offer message submission over port 587 require clients to use STARTLS to upgrade the connection and also require a login to authenticate. There has been an added benefit to this approach as well. By moving users away from using port 25 for email submission, ISPs are now able to block outgoing port 25 connections from users' computers, which were a significant source of spam due to user computers that were infected with spam sending viruses.
Currently, things seem relatively randomly split between people using SMTP SSL/TLS encrypted over port 465, or people using SMTP with STARTTLS upgrading over port 587.
根据这篇文章的说明starttls最开始是以纯文本协议来进行连接和协商的,作为客户端的一方会询问服务器端是否支持ssl/tls加密,如果服务器端回答支持,那么客户端就开始以ssl/tls的方式发送数据,如果服务器端不支持,那么还用原来的方式来发送数据。
不过遇到过这样一个问题,采用普通的smtp发送邮件时是OK的,在增加了支持starttls的声明后,却无法发送了,在用telnet命令测试服务器端是否支持starttls时,服务器端返回了 starttls ready,说明服务器端应该是支持starttls的,即便不支持,按理也应该能够支持普通的方式发送邮件才对,可确实发送失败了,目前还找不到原因。
相应的邮件发送代码如下:
相关推荐
【解决漏洞-亲测好用】SSLTLS 服务器瞬时 Diffie-Hellman 公共密钥过弱
SSL与TLS【大牛Eric Rescorla 编著】 本书适用于任何想要理解和使用SSL/TLS 的读者。 对设计者来说,本书不但提供了已经付诸使用的技术库,还提供了使用SSL/TLS 来设计系统的有关信息。 对于使用SSL/TLS 编程的...
SSL and TLS Theory and Practice.pdf SSL and TLS Theory and Practice.pdf SSL and TLS Theory and Practice.pdf SSL and TLS Theory and Practice.pdf SSL and TLS Theory and Practice.pdf SSL and TLS Theory ...
Implementing SSL TLS Using Cryptography and PKI.pdf
邮箱 email 支持 qq邮箱 ssl tls 国外大神的作品,几分钟配置好,立马能用,qq邮箱用的是ssl,端口465
基于流谱理论的SSLTLS协议攻击检测方法.docx
全英文,用Java实现SSL TLS,在谷歌上找到的很实用的文档,特意转来分享。
基于SSLTLS的安全文件传输系统基于SSLTLS的安全文件传输系统
SSL and TLS Theory and Practice(2nd) 英文无水印原版pdf 第2版 pdf所有页面使用FoxitReader、PDF-XChangeViewer、SumatraPDF和Firefox测试都可以打开 本资源转载自网络,如有侵权,请联系上传者或csdn删除 ...
.net中为 SSL/TLS 安全通道建立信任关系
最新版本的TLS(Transport Layer Security,传输层安全协议)是IETF(Internet Engineering Task Force,Internet工程任务组)制定的一种新的协议,它建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本。在TLS与SSL...
本程序基于SSL/TLS协议的三元组认证的安全文件传输系统的设计和实现。采用java实现,java对SSL/TLS协议和加密技术封装的比较好,有兴趣可以下下来看一下
使用python来解析加密数据包,可通过pycharm安装Scapy-ssl_tls库文件,但库文件经常会安装失败,因此需要考虑直接安装python对应版本的Scapy-ssl_tls库文件
详细的介绍ssl和tls
Windows Server 合规漏洞修复,修复Windows Server CVE-2016-2183 SSL/TLS协议信息泄露漏洞修复脚本,基于Windows PowerShell, 兼容Windows Server 2016/2019,防止Sweet32 生日攻击
Bulletproof SSL and TLS by Ivan Ristić Table of Contents Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...
HTTPS权威指南 在服务器和WEB应用上部署SSL TLS和PKL 英文版
解决 SSL/TLS协议信息泄露漏洞(CVE-2016-2183) ps1 文件
XEP-0035 SSL TLS Integration