DTLS学习笔记 -- RFC 4347- 6347

本文介绍了DTLS协议的基础概念,对比了其与TLS的主要区别,并详细解释了为适应UDP传输而作出的改动。此外,还提供了DTLS握手流程的概述及一个简单的实现案例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

想学习一下dtls,是因为想以后没有公司免费VPN可用的时候,我能买一个主机,自己建一个VPN。

 

1.介绍

Web, email大多用TLS协议来做安全的网络传输,它们必须跑在可靠的TCP传输通道里。

如果传输的是实时媒体数据,那么重传丢掉的包就没有意义,这个时候,我们希望它是跑在UDP传输通道里。

再有,应用层协议SIP可以用TCP或UDP来传,但我们更希望是UDP的。于是有了DTLS。 

 

2. TLS有一些不同:

    1)TLS不能单独对某个记录进行完整性检查,如果记录N没收到,那记录N+1无法被认证。因为MAC值是通过序列号计算的,而记录里并没有显示的包含序列号段。

    2)TLS握手协议不用考虑丢包的问题

 

3.DTLS是跑在UDP上的TLS,这做了一些改变解决了几个问题

    1) 禁止流加密。这样可以保证记录间加密上下文的独立性。

    2) 给记录增加一个显示的序列号字段用来做重放攻击保护和记录数据认证。 

    3) 给握手包加入重传机制。为了requeset启用一个timer,如果没有收到response,而timer超时,那就重传request.

    4) 保证握手包的顺序。每个握手包是有序列号的,如果不是期望收到的握手包,那么把它放入队列。如果是,立刻处理。

    5) 消息的size。UDP包如果大于1500会被分片。所以每个DTLS握手报文包含一个段偏移和段长,如此便可还原被分片的握手报文。

    6)重放保护。维护一个接收报文的bitmap window。过老的报文或者收到过的包都被扔掉。

 

4. DTLS记录的格式。除了上面提到的一些不同,很多字段和应用场景与TLS相同。

 

5. DTLS握手协议。DTLS握手协议基本与TLS相同,只有三个变化:

    1) 加入一个无状态的cookie交换,以防止dos攻击。(就是给每一个请求连接的IP地址分配一个Cookie,如果短时间内连续受到某个IP的重复报文,就丢弃它)

        

               

    2) 修改握手包头来处理丢包,重排序和IP包分片问题。

    3) 重传timer,来处理丢包丢传问题。 

 

6. DTLS握手包头,body较多不贴图了,细节参见RFC.

 

 

7. 握手流程

    

 

 

8.我写了一个简单的例子,client用dtls协议发送一个字符串到server的5000端口,在Mac OS上编译通过,正常工作。

https://github.com/andyhu-hz/mycode/tree/master/dtls_test

 

9.openssl中关于SSL_pending的一个错误认识。

开始以为SSL_pending是用来检测有数据到来的,当SSL_pending返回一个非零正整数时,再调用SSL_Read从buffer中读取数据。

事实上SSL_pending一直返回零,有人也遇到了类似的问题。见这里http://stackoverflow.com/questions/6616976/why-does-this-ssl-pending-call-always-return-zero 

 

You are using SSL_pending() the completely wrong way. OpenSSL uses a state machine, whereSSL_pending() indicates if the state machine has any pending bytes that have been buffered and are awaiting processing. Since you are never calling SSL_read(), you are never buffering any data or advancing the state machine.

 

 If the SSL_pending function returns a return code of 0, it does not necessarily mean that there is no data immediately available for reading on the SSL session. A return code of 0 indicates that there is no more data in the current SSL data record. However, more SSL data records may have been received from the network already. If the SSL_pending function returns a return code of 0, issue the select function, passing the file descriptor of the socket to check if the socket is readable. Readable means more data has been received from the network on the socket.
 

 

转载于:https://www.cnblogs.com/awiki/p/4376996.html

包含了1-3093的rfc中文翻译。 组织:中国互动出版网(http://www.china-pub.com/) RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm) E-mail:ouyang@china-pub.com 译者: 李超(licc_li licc_li@sina.com) 译文发布时间:2001-5-23 版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须 保留本文档的翻译及版权信息。 Network Working Group S. Casner Request for Comments: 2508 Cisco Systems Category: Standards Track V. Jacobson Cisco Systems February 1999 低速串行链路下IP/UDP/RTP数据包头的压缩 (RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links) 本备忘录的状态 本文档讲述了一种Internet社区的Internet标准跟踪协议,它需要进一步进行讨论和建议以 得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化程度 和状态。本备忘录的发布不受任何限制。 版权声明 Copyright (C) The Internet Society (1999). All Rights Reserved. 摘要 本文描述了一种对IP/UDP/RTP数据报头进行压缩的方法,它可以降低在低速串行链路上 的网络开销。多数情况下,三个头可压缩到2-4字节。 请赐教并将您的建议发送到工作组邮件列表rem-conf@es.net或直接给作者。 本文中的关键字“必须”,“必须不”,“要求的”,“应该”,“不应该”,“会”,“不会”, “建议”,“或许”,“可选的”在 RFC 2119 中解释。 目录 本备忘录的状态 1 版权声明 1 摘要 1 1. 介绍 2 2. 设想和折中 2 2.1. 单工与全双工 3 2.2. 分片与分层 3 3.压缩算法 3 3.1.基本概念 3 3.2 RTP数据包头压缩 4 3.3协议 5 3.4. RTCP控制包压缩 12 3.5.非RTP UDP包压缩 13 4.与分片的交互 13 5.压缩协商 13 6.致谢 14 7.参考文献 14 8. 安全性考虑 14 9.作者地址 15 10.版权声明 15 1. 介绍 随着实时传输协议(RTP)成为正式的RFC[1]发行,人们对于利用RTP实现不同的网络音视 频应用程序间互操作的兴趣也日益增长。然而,我们也注意到,当使用低速链路如14.4Kb/s 或28.8Kb/s拨号时,12字节的RTP头对于仅有20字节的负载而言开销实在太大。(为了减少 头占用的字节,一些已经在类似环境下存在的应用通常使用自定义的协议,而这样做的代价 就是削减了RTP相关的功能。) 事实上,正如在TCP中已经取得巨大成功,也可通过压缩技术来令IP/UDP/RTP包头变小。 这时,压缩可以针对于RTP头(在端到端应用中),或者IP,UDP,RTP的组合头(在Link-by-Link 应用中)。将40字节的组合头一起进行压缩比仅压缩12字节的RTP头更具实际效果,因为两 种情况下的结果大小均为约2-4字节。同时,由于延迟和丢失率都很低,对Link-by-Link应 用进行压缩性能上也更好。因此我们在这里定义的方法就是针对Link-by-link应用下 IP/UDP/RTP头进行组合压缩。 本文定义的压缩方案可应用于IPv4包、IPv6包或封装了多个IP头的包。为了能同时在IPv6 和IPv4下使用,这里定义的IP/UDP/RTP压缩符合[3]中规定的通用压缩框架。该框架把TCP 和非TCP定义为IP之上的两个传输类。本规范将IP/UDP/TCP从非TCP类中抽取出来创建为第三 类。 2. 设想和折中 本压缩方案的目标是,在不发送UDP校验和的情况下,将大多数包的IP/UDP/RTP头压缩到 2个字节,在带校验和时则压缩到4个字节。这一方案的提出主要是受使用14.4kb/s和 28.8kb/s拨号调制解调器发送音视频时遇到的相关问题所引起。这些链路提供全双工通信, 所以协议利用了这点,尽管协议在用于单工链路时可能性能会有所下降。该方案在本地链路 上往返时间(RTT)很低,从而实现性能最高。 为了降低低速链路下的延迟,除了在第四节中确定了分片和压缩中可能使用的一些交互 外,本规范并未提出大型数据包的分片和占先策略。分片方案可能会单独定义并与本压缩方 案配合使用。 应该注意到,实现的简单性是评价压缩方案的一个重要因素。通信服务器可能要用一个 处理器支持多达100个拨号调制解调器的数据压缩。因此,如下的考虑都是比较恰当的,即 在设计阶段为了实现简单而牺牲一些通用性,或者在设计上灵活通用但为了简单性可对设计 进行子集化。通过在压缩和解压器之间用更复杂的模型通信改变头字段还可以达成更好的压 缩效果,但其复杂性却是没必要的。下一节将讨论这里列出的一些折中方案。 2.1. 单工与全双工 在没有其它限制的情况下,单工链路上的压缩方案应成为首选。但为防止错误发生,单 工链路上的操作需要用一个含有压缩状态信息的未压缩包头进行周期性的刷新。如果明显的 错误信号可以返回,则恢复延迟也可以实质性地缩短,无错误情况的开销也会降低。为了实 现这些性能的优化,本规范包括了一个可逆向发送的明显错误指示。 在单工链路中,可以使用周期性刷新来取代。解压器一旦侦测到错误存在于某个特定的 流中,它可以简单地放弃该流中所有的包直到接收到一个未压缩的头为止,然后继续解压。 其致命弱点在于可能要在恢复解压前要放弃大量的包。周期性刷新的方法在[3]的3.3节中进 行描述,它应用于单工链路的IP/UDP/RTP压缩,或者应用于其它非TCP包流的高延迟链路。 2.2. 分片与分层 在低速链路上发送大型数据包所需时间而导致的延迟对于单向音频应用不算什么大问 题,因为接收方可以适应延迟变动。但对于交互式的交谈,最小端到端延迟是非常关键的。 对大的,非实时数据包进行分片以允许小的实时包在分片间隙进行传送可以降低这种延迟。 本规范只处理压缩,并且假定,如果包括分片,也将被处理为一个单独层。将分片和压 缩按这种方式进行集成并不可取,因为一旦如此,在没有必要或不可能进行分片的情况下, 连压缩都不能使用。类似地,应该避免预留协议的任何需求。除了要求链路层提供一些包类 型码,一个包长度指示和良好的错误检测外,该压缩方案可独立于任何其它机制而应用在本 地链路的两端。 相反,单独对IP/UDP和RTP层进行压缩丢失了太多的压缩效率,这些效率可以通过将它们 一起对待而得到。由于相同的函数可以应用于所有层,实现跨越这些协议层边界的方案是恰 当的。 3.压缩算法 本文定义的压缩算法主要利用了RFC 1144[2]描述的TCP/IP头压缩的设计。读者可以参考 该RFC获取更多的关于对包头进行压缩的基本动机和通用原理。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值