WO2008095382A1 - Procédé, système et appareil pour établir une connexion de sécurité de couche de transport - Google Patents

Procédé, système et appareil pour établir une connexion de sécurité de couche de transport Download PDF

Info

Publication number
WO2008095382A1
WO2008095382A1 PCT/CN2007/070467 CN2007070467W WO2008095382A1 WO 2008095382 A1 WO2008095382 A1 WO 2008095382A1 CN 2007070467 W CN2007070467 W CN 2007070467W WO 2008095382 A1 WO2008095382 A1 WO 2008095382A1
Authority
WO
WIPO (PCT)
Prior art keywords
domain name
server
client
tls
security information
Prior art date
Application number
PCT/CN2007/070467
Other languages
English (en)
French (fr)
Inventor
Yunbo Pan
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2008095382A1 publication Critical patent/WO2008095382A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a method, system and apparatus for establishing a secure connection at a transport layer.
  • DNS Domain Name System
  • IPsec Internet Protocol Security
  • SSH Secure Shell
  • Public key fingerprints etc.
  • DNSSEC is a DNS security extension. It uses the zone signature method to perform data source authentication and integrity protection on resource records. The so-called zone signature is to use the private key corresponding to each zone to each zone. A resource record set is signed to form a signature record corresponding to the resource record set.
  • the domain name resolver can determine the authenticity and integrity of the obtained resource record through signature verification.
  • DNSSEC establishes a chain of trust to ensure the reliability of the public key obtained by the domain name resolver. As the beginning of the chain of trust, each domain resolver must be pre-configured with one or more Trust Anchors. Trust Anchor is a certain A summary of the message for the public or public key of the zone.
  • the TLS (Transport Layer Security) protocol is a protocol that provides secure and reliable communication services for both parties on the Internet. It allows anti-eavesdropping, message tampering and message forgery between client/server applications. Secure communication.
  • the protocol consists of two layers, namely: the upper layer handshake protocol and the lower layer record layer protocol. The reason for this is to ensure the independence of the application protocol, so that the low-level protocol remains transparent to the advanced protocol.
  • the main functions of the handshake protocol are: 1. Responsible for the identity verification of both parties, mainly including mutual authentication, server authentication, and non-authentication;
  • the recording layer protocol is located on a reliable transmission protocol, such as the TCP protocol (Transmission Control Protocol), which uses the various algorithms and keys negotiated by the handshake protocol to segment, compress, and attach the data.
  • TCP Transmission Control Protocol
  • the MAC Message Authentication Code
  • the most widely used method is to use the certificate to distribute the server public key and authenticate.
  • the embodiments of the present invention provide a method, a system, and a device for establishing a transport layer secure connection without using a certificate authority, which can facilitate client acquisition, thereby simplifying the interaction process and improving security performance.
  • the embodiment of the invention discloses a method for establishing a secure connection of a transport layer, which comprises:
  • the client queries the domain name device to obtain security information of the transport layer secure TLS server;
  • the client connects to the TLS server according to the security information.
  • the embodiment of the invention further discloses a system for establishing a secure connection of a transport layer, comprising a client and a TLS server, and a domain name device, wherein: a TLS server, configured to store security information in the domain name device;
  • a client configured to query the domain name device to obtain the security information, and establish a connection with the TLS server according to the security information
  • a domain name device configured to save the security information of the TLS server.
  • an embodiment of the present invention further discloses a domain name device, including:
  • a recording module configured to store security information of the TLS server in the form of a resource record
  • an output module configured to output, according to a request of the client, the corresponding resource record in the recording module to the client.
  • an embodiment of the present invention further discloses a security extension server including a DNS server and a DNS of the above domain name device.
  • the domain name device of the secure extension server such as the DNS server or the DNS stores the security information of the TLS server, as long as there is a place where the Internet has the DNS, the application of the TLS protocol can be rid of the certificate authority. Binding, adding TLS application scenarios;
  • DNS has a globally standardized and standardized naming scheme, and each user has a clear and unique name
  • the user can obtain the public key of the communication peer and the zone public key used to verify the corresponding signature record online in time, and there is no possibility that the certificate cannot be verified because the user does not have the public key of the certificate authority.
  • FIG. 2 is a schematic diagram of a message flow of a TLS handshake protocol according to another embodiment of the present invention.
  • FIG. 3 is a schematic diagram of the composition of an embodiment of the system provided by the present invention.
  • Embodiment 4 is a schematic structural diagram of Embodiment 1 of a domain name device according to the present invention.
  • FIG. 5 is a schematic structural diagram of Embodiment 2 of a domain name device according to the present invention.
  • the security information of the TLS server is stored in the resource record of the domain name device, which is convenient for the client to obtain, thereby simplifying the interaction process and improving the security performance.
  • Step 101 The client queries the domain name device for obtaining the security information of the transport layer secure TLS server.
  • the domain name device may be a DNS or DNSSEC authoritative server.
  • whether to use the DNS or DNSSEC to store security information depends on the trade-off between communication security and efficiency of the services supported by the server.
  • Step 102 The client connects to the TLS server according to the security information.
  • the pre-master-secret is used to generate a key for the encryption algorithm and the message digest algorithm.
  • the client After obtaining the security information of the TLS server, the client performs pre-master-secret negotiation according to the related information, and establishes a connection after the negotiation is completed. .
  • the domain name device may actively store the security information of the TLS server itself, or receive and save its own security information sent by the TLS server, and the security information includes an algorithm of the public key and various parts of the public key. Length and content, of course, the security information may also include the highest version of the TLS protocol supported by the TLS server, which is stored in the domain name device in a specific resource record format.
  • the resource record is the data format in the DNS. All the data in the DNS can be stored in the form of resource records. There are many kinds of resource records, and the format is as follows:
  • the resource record type represents the external representation of different kinds of resource records
  • the data identifies different data formats of different kinds of resource records.
  • the device needs to use the private key of the area where the TLS server is located to sign the resource record to generate a signature record. If the TLS server under the same URL uses different security protection methods for different services, you can also add a field to identify the service in the resource record, or modify the naming format of the resource record, and add the service before the resource record name. The prefix of the name.
  • the client When a TLS connection is established, the client obtains the security information corresponding to the specific service by querying the domain name device. If the security information includes the highest version of the TLS protocol supported by the TLS server, the client can know the highest version number supported by the TLS server and the highest version supported by itself. For comparison of this number, take the lower one as the version number of the protocol used by this connection, and write the version number to the ClientHello message and send it to the TLS server. After receiving the ServerHello message returned by the TLS server, ServerHello will be sent. The version information in the version is compared with the version information in ClientHello. If the two are inconsistent, a transmission error or an attack may occur. At this time, the client may choose to interrupt the connection or issue a warning message; if the two are consistent, the connection is maintained.
  • the client After the client receives the HelloDone packet, if there is no ServerKeyExchange packet, the client can learn the key negotiation algorithm according to the key format stored in the resource record:
  • the client selects a re-master-secret after obtaining the public key, and uses the public key of the TLS server to perform the re-master-secret. Send it to the TLS server with the ClientKeyExchange message.
  • the TLS server decrypts the pre-master-secret with the corresponding private key. This ensures that both parties know the re-master-secret.
  • the client If the TLS server stores the exchange parameters of p, g, and server in the public key required for Diffie-Hellman exchange in the resource record, the client generates its own exchange parameters according to p and g, and generates according to the two exchange parameters.
  • Re-master-secret If the TLS server stores the exchange parameters of p, g, and server in the public key required for Diffie-Hellman exchange in the resource record, the client generates its own exchange parameters according to p and g, and generates according to the two exchange parameters.
  • the process of generating the pre-master-secret may be: After the client knows g and p, and randomly selects X, the client generates its own exchange parameter: g A x mod p, and the exchange parameter of the TLS server is 8 / 1110 (1, since only the client knows X, only the TLS server knows y, so the client can calculate (g A y mod p ) according to the exchange parameters and X of the TLS server.
  • a x g A xy mod
  • a y g A xy mod p, so that both parties get the same re-master-secret. Even if others know the exchange parameters of both parties, if they do not know x, y, they cannot calculate g A. Xy mod p.
  • the negotiation algorithm is DHE.
  • the public key stored in the resource record by the TLS server is used to verify the signature, not for direct key exchange.
  • the difference between the DHE key exchange algorithm and the DH exchange is:
  • the ⁇ p used for each negotiation is fixed, and the g and p used in the DHE algorithm are changing.
  • a new p, g combination is generated for each negotiation of the TLS server, and the exchange parameters are generated by the TLS server, and the TLS server notifies the client of the p, g and the key negotiation by the ServerKeyExchange message.
  • TLS server exchange parameters, in order to ensure the source authentication and data integrity of the contents of the ServerKeyExchange message, the TLS server needs The contents of g, g, and exchange parameters are signed, and the role of the public key in the resource record is used by the client to verify the signature.
  • the system embodiment for establishing a transport layer secure connection as shown in FIG. 3 includes a client 203, a domain name device 201, and a TLS server 202, where:
  • a TLS server 202 configured to store its security information in the domain name device 201;
  • the client 203 is configured to query the domain name device 201 to obtain the security information, and perform pre-master-secret negotiation with the TLS server 202 according to the security information.
  • the domain name device 201 is configured to save the security information of the TLS server 202, and send the security information to the client 203 when the client 203 queries;
  • the domain name device 201 can be a DNS server or a DNS security extension server.
  • a recording module 2011 and an output module 2012 are included, wherein:
  • the recording module 2011 is configured to store the security information of the TLS server in the form of a resource record; and the output module 2012 is configured to output, according to the request of the client 201, the corresponding resource record in the recording module 2011 to the client 201.
  • such a domain name device can be included in a secure extension server of a DNS server or DNS.
  • a signature module 2013 is further configured to store the record module 2011 according to the private key of the area where the TLS server 202 is located. Resource record signature.
  • the embodiments of the present invention may also be embodied in the form of a computer readable medium, which may be a medium containing, storing, communicating, transmitting or transmitting a computer program.
  • the computer readable medium can be an electronic, magnetic, electromagnetic, optical, infrared, or semiconductor system, apparatus, device, propagation medium, or computer memory.
  • DNS has a globally standardized and standardized naming scheme, and each user has a clear and unique name
  • the user can obtain the public key of the communication peer and the zone public key used to verify the corresponding signature record online in time, and there is no possibility that the certificate cannot be verified because the user does not have the public key of the certificate authority.

Description

建立传输层安全连接的方法、 系统及装置
本申请要求于 2007年 2月 6日提交中国专利局、申请号为 200710073234.9、 发明名称为"建立传输层安全连接的方法、系统及装置，，的中国专利申请的优先 权， 其全部内容通过引用结合在本申请中。
技术领域
本发明涉及通信技术领域， 尤其涉及建立传输层安全连接的方法、 系统及 装置。
背景技术
DNS (域名系统， Domain Name System )实际上是一个大型的分布式数据 库系统， 它所执行的基本功能是网络资源（从最早的简单网络上的每个主机名 到后来的域名、 邮件地址等 )与 IP地址之间的翻译。 由于 DNS是一个被广泛 应用的网络基础设施， 所以目前的 DNS被赋予了许多新的功能， 例如， 用它 来进行分发 IPsec ( Internet协议安全） 的公钥信息或 SSH (安全外壳， Secure Shell ) 的公钥指紋等。
DNSSEC是 DNS的安全扩展（ DNS Security Extension ), 它通过区签名的 方式来对资源记录进行数据源认证及完整性保护， 所谓区签名， 就是利用每个 区所对应的私钥对区内的每一个资源记录集作签名，形成与资源记录集对应的 签名记录。
通过获取一个区所对应的公钥，域名解析器可以通过签名验证来判断获得 的资源记录的真实性和完整性。 DNSSEC通过建立信任链来保证域名解析器所 获得的公钥的可靠性，作为信任链的开端，每个域名解析器都必须预先配置一 个或多个 Trust Anchor (信任锚点）， Trust Anchor为某个区的公钥或公钥的消 息摘要。
TLS (传输层安全， Transport Layer Security )协议是一个能为 Internet上 的通讯双方提供安全可靠的通讯服务的协议， 它允许客户端 /服务器应用之间 进行防窃听、防消息篡改及防消息伪造的安全通讯。该协议包含两个层次，即： 上层的握手协议和下层的记录层协议，这样做的原因是为了保证应用协议的独 立性， 使得低级协议对于高级协议保持透明。
握手协议的主要功能有： 1. 负责双方的身份验证， 主要有相互认证、 服务器认证、 无认证三种可 选方式；
2. 协商各种算法， 比如 pre-master-secret (预共享秘密） 的协商算法、 数 据的加密算法及压缩算法、数据的完整性保护算法，以及连接的版本号等信息； 3. 协商 pre-master-secret, 并据此生成各种数据保护算法所需的密钥。 记录层协议位于某一可靠的传输协议之上， 例如 TCP协议（传输控制协 议， Transmission Control Protocol ), 它利用握手协议所协商好的各种算法和密 钥， 对数据进行分段、 压缩、 附上 MAC ( Message Authentication Code, 消息 认证代码）、 加密， 然后将处理过的数据发送出去， 接收端则进行相反的处理。
为了验证通信双方的身份， 同时保证 pre-master-secret协商的安全性及机 密性， 目前应用最广泛的方法是利用证书来分发服务器公钥并进行身份验证。
在实现本发明实施例的过程中，发明人发现在这种方案中， 需要有证书机 构的支持， 而这样会直接导致通信代价的增加， 并且， 目前还没有任何证书机 构能得到所有潜在用户的信赖； 在目前所存在的诸多证书机构中， 不同的证书 机构可能使用不同的结构、 不同的安全策略和密钥算法体系， 这样会导致使用 不同证书的双方无法进行通信； 而且， 目前不存在一个有效的办法来保证客户 能快速、 安全的获得众多证书机构的公钥。
实体的命名也没有一个统一的标准， 比方说， 如果 A拥有一个由 CA1签 发的名为 Alice的证书，而 B则完全可以拥有一个由 CA2签发的同样名为 Alice 的证书， 这样， 客户端 C就将无法辨别同为 Alice的八、 B的身份。
发明内容
本发明实施例提供一种不使用证书机构而建立传输层安全连接的方法、系 统及装置， 能够方便客户端获取， 从而简化交互过程， 提高安全性能。
本发明实施例的技术方案是这样实现的：
本发明实施例公开了一种建立传输层安全连接的方法， 包括：
客户端向域名设备查询获取传输层安全 TLS服务器的安全信息；
所述客户端根据所述安全信息与所述 TLS服务器进行连接。
本发明实施例还公开了一种建立传输层安全连接的系统， 包括客户端和 TLS服务器， 还包括域名设备， 其中： TLS服务器， 用于将安全信息存储到所述域名设备中；
客户端， 用于向所述域名设备查询获取所述安全信息，根据所述安全信息 与所述 TLS服务器建立连接；
域名设备， 用于保存所述 TLS服务器的所述安全信息。
另外， 本发明实施例还公开了一种域名装置， 包括：
记录模块， 用于以资源记录的形式存储 TLS服务器的安全信息； 输出模块， 用于根据客户端的请求， 向所述客户端输出所述记录模块中的 相应资源记录。
另外， 本发明实施例还公开了一种包括上述域名装置的 DNS 服务器和 DNS的安全扩展服务器。
在本发明的实施例中， 由于釆用诸如 DNS服务器或者 DNS的安全扩展 服务器的域名设备存储 TLS服务器的安全信息， 只要有 Internet的地方就有 DNS, 这样 TLS协议的应用就可以摆脱证书机构的束缚， 增加 TLS的应用场 景；
而且 DNS具备全球统一的规范化命名方式， 每个用户都有一个明确且唯 样的名字的情况；
用户可以及时在线获得通信对端的公钥及用以验证对应签名记录的区公 钥， 不会出现因为用户没有证书机构的公钥而无法验证证书的情况。
附图说明
图 1为本发明一实施例的流程示意图；
图 2为本发明另一实施例的 TLS握手协议的消息流示意图；
图 3为本发明所提供的系统的一个实施例的组成示意图；
图 4为本发明域名装置实施例一组成示意图；
图 5为本发明域名装置实施例二组成示意图。
具体实施方式
在本发明的实施例中， 将 TLS服务器的安全信息存放在域名设备的资源 记录中， 方便客户端获取， 从而简化交互过程， 并提高了安全性能。
为使本发明的目的、 技术方案和优点更加清楚明白， 以下举实施例， 并参 照附图， 对本发明进一步详细说明。
在如图 1所示的本发明实施例流程图中：
步骤 101 : 客户端向域名设备查询获取传输层安全 TLS服务器的安全信息； 在本发明的实施例中， 域名设备可以是 DNS或者 DNSSEC权威服务器， 在 支持 DNSSEC的网络环境下， 究竟釆用 DNS还是 DNSSEC来存储安全信息取决 于服务器所支持的业务对通信安全及效率的权衡。
步骤 102: 客户端根据所述安全信息与 TLS服务器进行连接。
pre-master-secret是用来生成加密算法、 消息摘要算法的密钥， 客户端在 获取所述 TLS服务器的安全信息后，根据其中的相关信息进行 pre-master-secret 协商， 协商完成后建立连接。
在本发明的实施例中， 域名设备可以主动存储 TLS服务器自身的安全信 息， 或者是接收 TLS服务器发送来的自身的安全信息并加以保存， 这些安全 信息包括公钥的算法、 公钥各个部分的长度及内容， 当然， 安全信息中还可以 包括 TLS服务器所支持 TLS协议的最高版本， 它们以特定的资源记录格式存 入域名设备中。
资源记录是 DNS中的数据格式，所有 DNS中的数据都可以以资源记录的 形式存储， 资源记录有很多种， 其格式如下：
资源记录名 网络类别 资源记录类型 生存时间 数据
其中， 资源记录类型代表不同种类资源记录的外在表现， 而数据则标识不 同种类的资源记录不同的数据格式。
而且， 在支持 DNSSEC的情况下， 设备需要利用 TLS服务器所在区域的 私钥对该资源记录签名， 生成签名记录。 如果同一个网址下的 TLS服务器针 对不同的业务釆用不同的安全保护方式，那么在资源记录中还可以加入用以辨 别业务的字段， 或者修改资源记录的命名格式，在资源记录名前加上业务名的 前缀。
在如图 2所示的 TLS握手协议的消息流示意图中：
在建立 TLS连接时， 客户端通过查询域名设备获得特定业务所对应的安 全信息。 如果安全信息中包括 TLS服务器所支持 TLS协议的最高版本， 客户 端可以在获知 TLS服务器所支持的最高版本号后， 将之与自身支持的最高版 本号比较，取其中较低的一个作为本次连接所釆用协议的版本号， 并将该版本 号写入 ClientHello 消息中发送至 TLS 服务器， 在收到 TLS 服务器返回的 ServerHello消息后， 将 ServerHello中的版本信息与 ClientHello中的版本信息 比较， 如果两者不一致， 则可能出现了传输错误或受到了攻击， 此时客户端可 以选择中断连接或发出警告消息； 如果两者一致， 则保持连接。
在客户端接收到 HelloDone报文后， 如果没有 ServerKeyExchange报文， 则客户端可以根据资源记录中所存储的密钥格式获知密钥协商算法：
如果资源记录中存储有服务器的 RSA公钥， 客户端在获取该公钥后， 选 择一个 re-master-secret, 利用 TLS月良务器的公钥 , 对 re-master-secret进行力口 密， 用 ClientKeyExchange消息将它发给 TLS服务器， TLS服务器利用对应的 私钥解密得出 pre-master-secret, 这样可以保证双方知道该 re-master-secret;
如果 TLS服务器将进行 Diffie-Hellman交换所需的公钥中的 p、 g及 server 的交换参数存储在资源记录中， 客户端根据 p、 g产生自己的交换参数， 根据 两个交换参数即可生成 re-master-secret„
其中， 产生 pre-master-secret的过程可以是： 客户端获知 g、 p后， 随机选 取 X , 则客户端生成自己的交换参数： gAx mod p, 而 TLS服务器的交换参数 为 8/ 1110(1 ， 由于只有客户端知道 X , 只有 TLS服务器知道 y, 因此客户端 可以根据 TLS服务器的交换参数和 X计算 （ gAy mod p ) Ax=gAxy mod , TLS 月良务器计算 (gAx mod p)Ay=gAxy mod p,从而双方得到同样的 re-master-secret , 他人即使知道了双方的交换参数， 如果不知道 x、 y, 则还是无法计算出 gAxy mod p。
如果客户端收到 ServerKeyExchange报文，则协商算法为 DHE, TLS服务 器存储在资源记录中的公钥是用来验证签名的， 而非用来进行直接密钥交换 的。 DHE密钥交换算法和 DH交换的区别在于： TLS服务器和客户端利用 DH 算法来协商密钥时， 每次协商所用的^ p是固定的， 而 DHE算法中所釆用的 g、 p是可变的。 在 DHE算法中， 对于每次协商 TLS服务器都将产生一个新的 p、 g组合， 并以此产生自身的交换参数， TLS服务器通过 ServerKeyExchange 消息来通知客户端此次密钥协商的 p、 g以及 TLS服务器的交换参数， 为了保 证 ServerKeyExchange消息中的内容的源认证及数据完整性， TLS服务器需要 对 、 g及交换参数等内容进行签名， 而资源记录中的公钥的作用就是由客户 端用来验证签名。
如图 3所示的建立传输层安全连接的系统实施例中， 包括客户端 203、域名 设备 201和 TLS服务器 202, 其中：
TLS服务器 202, 用于将其安全信息存储到域名设备 201中；
客户端 203 , 用于向域名设备 201查询获取所述安全信息，根据所述安全信 息与 TLS服务器 202进行 pre-master-secret协商；
域名设备 201 , 用于保存所述 TLS服务器 202的安全信息， 并当所述 客户端 203查询时， 将所述安全信息发送给所述客户端 203 ;
一般而言， 域名设备 201可以是 DNS服务器或者 DNS的安全扩展服 务器。
在如图 4所示的域名装置实施例中， 包括记录模块 2011和输出模块 2012 , 其中：
记录模块 2011 , 用于以资源记录的形式存储 TLS服务器的安全信息； 输出模块 2012, 用于根据客户端 201的请求， 向所述客户端 201输出所述记 录模块 2011中的相应资源记录。
一般情况下，这样的域名装置可以包含在 DNS服务器或 DNS的安全扩展 服务器中。
当然， 当域名装置包含在 DNS的安全扩展服务器中时，还可以如图 5所示， 包括一个签名模块 2013 , 用于根据所述 TLS服务器 202所在区域的私钥对所述 记录模块 2011存储的资源记录签名。
可以理解的是， 本发明实施例还可以计算机可读介质的形式独立存在， 而 这样的计算机可读介质可以是包含、 存储、 传达、 传播或者传输计算机程序的 介质， 所述计算机程序为使用指令以运行本发明实施例所提供的系统装置、 系 统或者设备的程序， 或者是与该指令有关的程序。 该计算机可读介质可以是电 子、 磁、 电磁、 光学、 红外或者半导体的系统、 装置、 设备、 传播介质或者计 算机存储器。
可以看出，由于釆用诸如 DNS服务器或 DNS的安全扩展服务器的域名设 备存储 TLS服务器的安全信息， 只要有 Internet的地方就有， 这样 TLS协议 的应用就可以摆脱证书机构的束缚， 增力。 TLS的应用场景；
而且 DNS具备全球统一的规范化命名方式， 每个用户都有一个明确且唯 样的名字的情况；
用户可以及时在线获得通信对端的公钥及用以验证对应签名记录的区公 钥， 不会出现因为用户没有证书机构的公钥而无法验证证书的情况。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通 技术人员来说， 在不脱离本发明原理的前提下， 还可以做出若干改进和润饰， 这些改进和润饰也应视为本发明的保护范围。

Claims

权 利 要 求
1、 一种建立传输层安全连接的方法， 其特征在于， 包括：
客户端向域名设备查询获取传输层安全 TLS服务器的安全信息；
所述客户端根据所述安全信息与所述 TLS服务器进行连接。
2、 如权利要求 1所述的方法， 其特征在于， 所述客户端向域名设备查询获 取传输层安全 TLS服务器的安全信息， 具体为：
客户端向域名设备查询获取传输层安全 TLS服务器存储到所述域名设备 中的安全信息。
3、如权利要求 2所述的方法，其特征在于，所述安全信息包括公钥的算法、 内容及长度。
4、 如权利要求 3所述的方法， 其特征在于， 当所述域名设备为域名系统 DNS的安全扩展服务器时， 还包括：
所述 TLS服务器将所述公钥的算法、 内容及长度， 以资源记录的形式存储 到所述域名设备中；
所述域名设备利用所述 TLS服务器所在区域的私钥对所述资源记录签名。
5、 如权利要求 4所述的方法， 其特征在于， 所述资源记录中还包括标识业 务的字段。
6、如权利要求 4所述的方法，其特征在于，在所述资源记录的命名格式中， 服务器的 DNS域名前包括业务名的字段。
7、 如权利要求 1至 6任一所述的方法， 其特征在于， 所述安全信息还包括 所述 TLS服务器支持的 TLS协议的最高版本号；
在所述客户端向域名设备查询获取传输层安全 TLS服务器的安全信息后， 还进一步包括：
所述客户端将获取的所述最高版本号与自身所支持的最高版本号中间的 较低者发送给所述 TLS服务器，根据所述 TLS服务器返回的包含版本号的消息， 确定返回的所述版本号与发送给所述 TLS服务器的版本号不同， 则中断连接或 发警告消息。
8、 如权利要求 1至 6任一所述的方法， 其特征在于， 所述域名设备为 DNS 服务器或者 DNS的安全扩展服务器。
9、 一种建立传输层安全连接的系统， 包括客户端和 TLS服务器， 其特征 在于， 还包括域名设备， 其中：
所述 TLS服务器， 用于将安全信息存储到所述域名设备中；
所述客户端， 用于向所述域名设备查询获取所述安全信息，根据所述安全 信息与所述 TLS服务器建立连接；
所述域名设备， 用于保存所述 TLS服务器的所述安全信息。
10、 根据权利要求 9所述的系统， 其特征在于， 所述域名设备为 DNS服务 器或者 DNS的安全扩展服务器。
11、 一种域名装置， 其特征在于， 包括：
记录模块， 用于以资源记录的形式存储 TLS服务器的安全信息； 输出模块， 用于根据客户端的请求， 向所述客户端输出所述记录模块中的 相应资源记录。
12、 如权利要求 11所述的装置， 其特征在于， 还包括：
签名模块， 用于根据所述 TLS服务器所在区域的私钥对所述记录模块存储 的资源记录签名。
13、 一种域名系统服务器， 其特征在于， 包括域名装置， 所述域名装置包 括：
记录模块， 用于以资源记录的形式存储 TLS服务器的安全信息； 输出模块， 用于根据客户端的请求， 向所述客户端输出所述记录模块中的 相应资源记录。
14、 如权利要求 13所述的域名系统服务器， 其特征在于， 所述域名装置还 包括：
签名模块， 用于根据所述 TLS服务器所在区域的私钥对所述记录模块存储 的资源记录签名。
15、 一种域名系统的安全扩展服务器， 其特征在于， 包括域名装置， 所述 域名装置包括：
记录模块， 用于以资源记录的形式存储 TLS服务器的安全信息； 输出模块， 用于根据客户端的请求， 向所述客户端输出所述记录模块中的 相应资源记录。
16、 如权利要求 15所述的域名系统的安全扩展服务器， 其特征在于， 所述 域名装置还包括：
签名模块， 用于根据所述 TLS服务器所在区域的私钥对所述记录模块存储 的资源记录签名。
PCT/CN2007/070467 2007-02-06 2007-08-14 Procédé, système et appareil pour établir une connexion de sécurité de couche de transport WO2008095382A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710073234.9 2007-02-06
CN2007100732349A CN101242426B (zh) 2007-02-06 2007-02-06 建立传输层安全连接的方法、系统及装置

Publications (1)

Publication Number Publication Date
WO2008095382A1 true WO2008095382A1 (fr) 2008-08-14

Family

ID=39681255

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2007/070467 WO2008095382A1 (fr) 2007-02-06 2007-08-14 Procédé, système et appareil pour établir une connexion de sécurité de couche de transport

Country Status (2)

Country Link
CN (1) CN101242426B (zh)
WO (1) WO2008095382A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9130917B2 (en) * 2011-05-02 2015-09-08 Verisign, Inc. DNSSEC signing server
CN103078877B (zh) * 2013-01-31 2015-09-16 中国科学院计算机网络信息中心 基于dns的用户认证和域名访问控制方法及系统
CN104217327B (zh) * 2014-09-25 2017-12-26 中孚信息股份有限公司 一种金融ic卡互联网终端及其交易方法
CN106470248B (zh) * 2015-08-19 2019-08-27 互联网域名系统北京市工程研究中心有限公司 Dnssec签名服务的热备方法及系统
CN105141612A (zh) * 2015-09-01 2015-12-09 中国互联网络信息中心 一种dns数据包隐私保护方法
CN106534086B (zh) * 2016-10-31 2019-08-30 深圳数字电视国家工程实验室股份有限公司 一种设备认证方法、终端设备、服务器及系统
CN106817367A (zh) * 2017-01-03 2017-06-09 深圳市沃特玛电池有限公司 一种数据传输方法和系统
CN107613039B (zh) * 2017-09-19 2020-11-20 北京小米移动软件有限公司 Ip地址归属地查询方法、装置、系统及存储介质
WO2021022406A1 (zh) * 2019-08-02 2021-02-11 华为技术有限公司 一种身份验证方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060067340A1 (en) * 2004-09-29 2006-03-30 Johannes Ruetschi Methods and apparatus for managing TLS connections in a large soft switch
US20060294381A1 (en) * 2005-06-22 2006-12-28 Mitchell Douglas P Method and apparatus for establishing a secure connection
EP1743449A1 (en) * 2004-05-03 2007-01-17 Nokia Corporation Handling of identities in a trust domain of an ip network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1743449A1 (en) * 2004-05-03 2007-01-17 Nokia Corporation Handling of identities in a trust domain of an ip network
US20060067340A1 (en) * 2004-09-29 2006-03-30 Johannes Ruetschi Methods and apparatus for managing TLS connections in a large soft switch
US20060294381A1 (en) * 2005-06-22 2006-12-28 Mitchell Douglas P Method and apparatus for establishing a secure connection

Also Published As

Publication number Publication date
CN101242426A (zh) 2008-08-13
CN101242426B (zh) 2010-12-08

Similar Documents

Publication Publication Date Title
JP4600851B2 (ja) コンピュータシステム間でメッセージを通信するための安全なコンテキストの確立
US7496755B2 (en) Method and system for a single-sign-on operation providing grid access and network access
JP5599910B2 (ja) 暗号証拠の再検証に基づく認証委任
US8185938B2 (en) Method and system for network single-sign-on using a public key certificate and an associated attribute certificate
JP4746333B2 (ja) コンピューティングシステムの効率的かつセキュアな認証
US8340283B2 (en) Method and system for a PKI-based delegation process
WO2016107320A1 (zh) 网站安全信息的加载方法和浏览器装置
WO2008095382A1 (fr) Procédé, système et appareil pour établir une connexion de sécurité de couche de transport
US20060143442A1 (en) Automated issuance of SSL certificates
US20040103283A1 (en) Method and system for authentification of a mobile user via a gateway
WO2019178942A1 (zh) 一种进行ssl握手的方法和系统
JP2006260538A (ja) Ｗｅｂサービス用の信頼できる第三者認証
CN101567784A (zh) 一种获取密钥的方法、系统和设备
KR20220030298A (ko) 참여 엔티티에 대한 네트워크 식별자를 사용하여 블록체인과 연관된 트랜잭션을 용이하게 하는 컴퓨터 구현 시스템 및 방법
WO2022033350A1 (zh) 注册服务的方法及设备
CN116684093B (zh) 身份认证与密钥交换方法及系统
CN109995723A (zh) 一种域名解析系统dns信息交互的方法、装置及系统
CN114301612A (zh) 信息处理方法、通信设备和加密设备
JP2004032699A (ja) 公開鍵証明書発行装置
IES20070726A2 (en) Automated authenticated certificate renewal system
CN117527421A (zh) 一种实现http协议安全传输的方法
Ho et al. A comparison of secure mechanisms for mobile commerce
CN117716666A (zh) 用于向用户提供自主身份云服务的方法、云服务方法、云服务器、自主身份方法
CA2374195C (en) System and method of looking up and validating a digital certificate in one pass
Hovlandsvåg Authenticating HTTPS servers through the use of DNS in an Offline Personal Authentication Device (OffPAD)

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07800943

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07800943

Country of ref document: EP

Kind code of ref document: A1