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的,即便不支持,按理也应该能够支持普通的方式发送邮件才对,可确实发送失败了,目前还找不到原因。
相应的邮件发送代码如下:
相关推荐
TAC顶刊报告:'多智能体分布式自适应一致性控制(含纯一致性与leader-follower一致性)'及其Matlab复现代码.pdf
SVPWM仿真与基于DSP28335的PIL(处理器在环)仿真模型验证算法可行性与实时性的实践研究.pdf
VSG仿真、并网与离网运行仿真、预同期并网控制及虚拟同步机逆变器仿真.pdf
SSA-RF与RF神经网络多元回归预测(Matlab 程序及运行指南).pdf
Simulink微网多逆变器下垂控制仿真模型:固定与可调的下垂系数、SVPWM与算法控制的并联运行.pdf
电磁场与电磁波28
SSA-CNN-LSTM时间序列预测(Matlab)_ 麻雀算法优化卷积长短期记忆网络.pdf
C++知识点汇总.md.zip
T型逆变器仿真(SPWM)Matlab 2021a:LCL滤波器下纯阻性负载的五电平波形仿真.pdf
STM32G431 FOC线性磁链观测器无感FOC驱动资料(非VESC、非ST电机库生成,支持直接零速闭环启动及电位器转速控制)”.pdf
STM32F103 SAE CAN开放协议源码(含半年咨询费+中文注释及原理说明).pdf
Java项目springboot基于springboot的课程设计,包含源码+数据库+毕业论文
Simulink导弹制导系统仿真模型文件使用指南及视频讲解.pdf
内容概要:本文深入介绍了Caffe深度学习框架,涵盖其历史背景和发展、安装配置、卷积神经网络(CNN)的基础理论及其实现。具体内容包括CNN各个层级的工作原理、Caffe中的网络模型定义和训练方法、LeNet与AlexNet的实际运用、迁移学习及模型的性能优化等。通过详细的实战操作演示,文章帮助开发者掌握在Caffe上搭建CNN的方法和技术。 适合人群:从事计算机视觉领域的研究人员和工程师,尤其是想要深入了解卷积神经网络和掌握Caffe框架的人群。 使用场景及目标:本文适合作为学习材料用于理解卷积神经网络的概念和工作机制,指导初学者和有经验的开发者如何利用Caffe实现图像识别、目标检测等任务;并且帮助读者掌握模型训练和性能优化的相关技能。 其他说明:文中提供了大量代码片段与实例讲解,方便读者理解和实践;此外还对比了几款主流深度学习框架的优势,辅助决策选用合适的开发工具。
1、文件说明: Centos8操作系统vim-editorconfig-1.1.1-1.el8.rpm以及相关依赖,全打包为一个tar.gz压缩包 2、安装指令: #Step1、解压 tar -zxvf vim-editorconfig-1.1.1-1.el8.tar.gz #Step2、进入解压后的目录,执行安装 sudo rpm -ivh *.rpm
VMD信号分解算法:VMD功率分解与滚动轴承故障检测.pdf
STM32 IAP固件升级程序源代码(串口环形队列接收模式实现固件升级程序).pdf
VSC直流输电仿真案例:两电平结构换流站与双环控制的应用.pdf
STM32高压无感FOC全功能版本:风机控制与独特处理方式.pdf
STM32单片机指纹密码锁仿真:键盘解锁、指纹识别及多功能安全控制程序.pdf