在HTTP/1.1中升级到TLS( 四 )


值是由这些定义的:
1. HTTP/1.1标准草案
2. Web分布式创作及版本[4][定义420-424]
3. WebDAV高级集合[5](正在制订)[定义425]
4. 第6节[定义426]
要加入到该名字空间的值应该以标准记录文档格式提交IETF应用组 。任何这种文档应该通
过HTTP/1.1[1]草案的状态词“过时”或“更新”使得可追踪来源 。
7.2HTTP升级记号登记
HTTP升级记号登记为产品记号定义了名字空间,该名字空间用于在升级HTTP头部域中
分辩协议 。每一个登记的记号应该同一个或一组规范相联系并有相联系的信息 。
HTTP/1.1[1]标准草案定义了这些遵从产品生产的记号:
产品(prodUCt)=记号["/"产品版本]
产品版本=记号
如BCP26[10]中描述的,登记应该基于先来先服务的原则 。这些定义不需要是IETF文
档或是IESG关注的课题,但应该遵守下列原则:
1. 一个记号一旦登记,就永远是登记了的 。
2. 登记必须指定一个负责登记的团体 。
3. 登记必须指定一个联系办法 。
4. 登记必须指定记号需要的文档 。
5. 负责的团体可以随时改变登记项 。IANA将记录下所有这种改变,并使它对需要的人可
用 。
6. 对一个“产品”记号第一次登记负责的团体在他们能够登记前必须同意同“产品”记号
一起的“版本”记号的晚些时候的登记 。
7. 若确实需要,IESG可以重新指定一个记号的负责团体 。通常这只是在负责团体无法联
系到时才会这样 。
本规范定义协议记号“TLS/1.0”作为TLS协议[6]定义的协议的标识符号 。
并不要求升级记号的定义是公众可用的,但登记的联系信息应该是 。
8.安全考虑
潜在的中间人攻击(删除升级头部)和目前http/https混用一样:
.移去升级头与重写网页来将https://links改变为http://links类似 。
.只有在服务器首先通过安全或不安全的通道公开这类信息才会造成这种风险 。
.若客户知道服务器可处理TLS,它就会坚持发送不带选项如OPTIONS的升级请求 。
.最后如https:定义警告的,“用户应该仔细检查服务器提供的证书以确定是否符合他
们的期望 。
此外,对于未明确激活TLS的客户,服务器可在响应中使用除了101或426的升级头来
通告TLS能力 。既然TLS能力应该作为服务器的特性而不是就在手边的资源,它应一次发送
就足够,让客户知道这个事实以在需要时使用 。
8.1https:URI方案含义
本备忘录没有影响‘https’的含义,广泛采用的超文本内容可以使用‘http’来区分
安全和不安全的资源 。
连接时安全特性的选择留给客户和服务器 。这答应每一方用任何可用的信息作出决
定 。例如,用户代理可以依靠有关网络安全方面的用户设置,如“对不在我的本地网络上
的所有POST操作都要求使用TLS”,或服务器可应用如‘本页面的FORM的提交和处理必须
用TLS’等资源存取规则 。
8.2CONNECT的安全考虑
一个类属的TCP通道是布满安全风险的 。首先,这种授权应该被限制在一小部分端
口 。这里定义的升级机制只是在80端口的隧道上需要 。第二,既然隧道数据对代理不透
明,对其它众所周知和保留端口的隧道有额外的风险 。例如,假定一个HTTP客户连接到25
端口,他可以通过SMTP传播垃圾邮件 。
参考
[1]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,Masinter,L.,
Leach,P.andT.Berners-Lee,"HypertextTransferProtocol--
HTTP/1.1",RFC2616,June1999.
[2]Berners-Lee,T.,Fielding,R.andL.Masinter,"URIGeneric
Syntax",RFC2396,August1998.

推荐阅读