[ipsec][crypto] ike/ipsec与tls的认证机制比较

前言

接上篇:[ipsec][crypto] 有点不同的数字证书到底是什么

本篇内容主要是上一篇内容的延伸。抽象的从概念上理解了证书是什么之后,我们接下来

从实践的角度出发,以IKEv2和TLS两个协议为例子,熟悉一下数字证书认证在协议上的实现。

author: classic_tong, date:20190914

一 IKE

我是利用strongswan来搭建的这样的实验环境的。协商双方配置为使用证书的方式。

为此我自签名了一个根证书,并为IKE双方各自签名了其证书。

生成自签名的证书的方法可以见:[ipsec][strongswan] 用strongswan pki工具生成自签名证书

1.1 strongswan的配置

生成好证书,并安放到指定位置后,使用类似如下的配置:

connections {
        net-net {
                remote_addrs = 192.168.8.103
                local {
                        auth = pubkey
                        certs = t129Cert.pem
                }
                remote {
                        auth = pubkey
                        id = "C=CH, O=t9, CN=t9.tong.localhost"
                }

这里,我们可以看到,id的配置,就是证书中的subject。(情回顾上一篇文章中的内容,明确的建立了用户与名字之间的逻辑链条)

1.2 协商过程分析

首先,参考[ipsec] 特别硬核的ike/ipsec NAT穿越机制分析 的第一章,请在理解了IKE交互的前提下,继续后续内容。

见下图,我们能见到,认证过程发生在第二次交互中。ike双方发送了自己的名字,和对方的名字,以及认证消息(通过私钥加密的内容,为了给对方认证,对方会通过

证书中的公钥解密,以此确认我方的身份合法)

author: classic_tong, date:20190914

我方用私钥加密的内容,已经在rfc中提前约定好。所以对方清楚解密后的内容应该是什么样子,才是正确的。大概内容就是上一个我方发送的数据包(也就是第一个通信数据包)。

响应端用户认证的内容是第二个通信数据包。

具体的内容见:https://tools.ietf.org/html/rfc7296#section-2.15

1.3 预共享秘钥的认证

顺便提及一下,预共享秘钥方式的认证。基本原理是一样的。只是在认证消息的计算过程中,加入了预共享秘钥信息。以此是无共享秘钥的人,我方计算出

数字签名的认证数据段。详见rfc:https://tools.ietf.org/html/rfc7296#section-2.15

除此之外,通信数据中的id信息也略有不同,见截图:

author: classic_tong, date:20190914

二 TLS

TLS的认证稍微有点复杂。我们先来说名字部分,如上一篇所述,名字是通过URL和证书中的SAN关联的。用户在浏览器中输入的域名必须在证书的SAN字段中存在。

才能通过用户到名字的逻辑链验证。然后,接下来说下一部分。先来看一下tls的信令交互图:

我们可以看见,server在验证client时,client分别发送了证书和证书verify数据给server用来验证,但是我们并没有看到server发送专门用来做认证

的消息段。原因是这样的,TLS的身份认证机制包含在里秘钥交互的机制中一同完成。

参考:https://security.stackexchange.com/questions/139176/details-of-tls-certificate-verification

https://tools.ietf.org/html/rfc5246#section-7.4.9

分RSA秘钥协商和DH秘钥协商两种情况来讨论。(我们是站在一般的https浏览应用来思考这个问题的,所以,这里只存在client验证server的单项讨论)

1. 使用RSA秘钥协商时,client会使用公钥加密一组私有内容发送给server来做秘钥协商。如果server没有私钥。协商结果一点是不一致的,最后client发送

过去的finish(11)消息将无法被正确解密,server也无法伪装出一个可以被正确解密的finished(13)消息发送回来。

In RSA key exchange, the client generates a random sequence of bytes and performs RSA encryption using the public key from the server‘s certificate. Then the client sends the resulting ciphertext to the server and expects the server to decrypt it (using the private key corresponding to the public key from the certificate) and use the random value in a KDF, together with other values, to generate symmetric keys and send a Finished message encrypted with the resulting symmetric keys. The client verifies the Finished message. The server can only succeed in generating the expected symmetric keys by decryption RSA encrypted message. https://tools.ietf.org/html/rfc5246#appendix-F.1.1.2

2. 使用DH时,server用私钥对消息(4)做了数字签名,client可以用公钥进行验证。

In DHE/ECDHE key exchange with PFS, the server signs its ephemeral key using the private key corresponding to the public key in the certificate and sends this in ServerKeyExchange. The client verifies the signature using the public key from the certificate. https://tools.ietf.org/html/rfc5246#appendix-F.1.1.3

author: classic_tong, date:20190914

原文地址:https://www.cnblogs.com/hugetong/p/11520458.html

时间: 2024-10-10 14:38:37

[ipsec][crypto] ike/ipsec与tls的认证机制比较的相关文章

[ipsec][crypto] 在IPSec ESP使用AES-GCM加密时的IV

IV IV是指初始化向量. 在我们当前讨论的场景中: 在IPSec ESP使用AES-GCM加密 IV有两个含义: 1. ESP报文封装时的IV,RFC中称为 AES-GCM IV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vect

[ipsec][crypto] 有点不同的数字证书到底是什么

前言 前言是在写完了全文之后回头补的.本意是想完全抽象的把证书的抽象逻辑意义表达出来,因为你能找到的大部分 资料都深陷在技术细节与行业规范里.只有其型没有其理,没有什么比理解一个事物的内在合理性更有乐趣的了. 所以忍不住表达的欲望想把他们写出来. 无奈改了几版,始终写的混乱.所以,每一个能读完的人,我都对你的支持表示感谢,如果有再深入讨论的 意愿,请和我联系. 很遗憾理解了九成,表达出来却只剩下五成.原谅我表达欠佳. [防扒乱入]  author: class_tong  date: 20190

[ipsec] 特别硬核的ike/ipsec NAT穿越机制分析

〇 前言 这怕是最后一篇关于IKE,IPSEC的文字了,因为不能没完没了. 所以,我一直在想这个标题该叫什么.总的来说可以将其概括为:IKE NAT穿越机制的分析. 但是,同时它也回答了以下问题: (1)IKE协议交互消息概述.(2)为什么IKE除了端口500还用了端口4500 .(3)IKE MOBIKE是什么. (4)迷之端口500和迷之端口4500 .(5)IKE/IPsec为什么要将端口500换成端口4500. (6)ike/ipsec为什么使用了两个端口. 另外,本篇的所有内容与讨论仅

FTP服务学习笔记之ssl/tls安全认证配置(3)

在Redhat5.8_X64bit上配置 一.实验说明 操作系统:Redhat5.8_x64bit 实验平台:VMware Workstation 实验目的:配置ftp基于ssl/tls安全认证 二.实验步骤如下: 1.安装vsftpd #yum install vsftpd #rpm -ql vsftpd #service vsftpd start #chkconfig vsftpd on 2.配置CA #cd /etc/pki/CA #mkdir certs newcerts crl #to

SSL/TLS双向认证案例参考

一.首先我们需要生成服务器端和客户端的数字证书并添加信任 实际应用环境里,需要向CA机构申请服务器证书.这里我们为了测试方便通过Keytool工具生成自签名证书来模拟. 注:相关参数说明请使用 keytool -help 查阅 1. 生成服务器端证书 keytool -genkey -v -keyalg RSA -keysize 1024 -sigalg SHA1withRSA -validity 36000 -alias www.alan.org -keystore alan.keystore

基于mosquitto的MQTT服务器---SSL/TLS 单向认证+双向认证

基于mosquitto的MQTT服务器---SSL/TLS 单向认证+双向认证 摘自:https://blog.csdn.net/ty1121466568/article/details/81118468 2018年07月19日 16:51:57 曾来过 阅读数:1632 本文为参考网上其他博文搭建出服务器后的步骤记录,如有冒犯,请私信!!! 目录... 3 第 1 章 安装Mosquitto. 4 1.1 方法一:手动编译安装... 4 1.2方法二:在Ubuntu下使用apt-get安装..

SSL/TLS协议运行机制的概述

转自:SSL/TLS协议运行机制的概述 作者: 阮一峰 日期: 2014年2月 5日 互联网的通信安全,建立在SSL/TLS协议之上. 本文简要介绍SSL/TLS协议的运行机制.文章的重点是设计思想和运行过程,不涉及具体的实现细节.如果想了解这方面的内容,请参阅RFC文档. 一.作用 不使用SSL/TLS的HTTP通信,就是不加密的通信.所有信息明文传播,带来了三大风险. (1) 窃听风险(eavesdropping):第三方可以获知通信内容. (2) 篡改风险(tampering):第三方可以

基于Token的WEB后台认证机制

几种常用的认证机制 HTTP Basic Auth HTTP Basic Auth简单点说明就是每次请求API时都提供用户的username和password,简言之,Basic Auth是配合RESTful API 使用的最简单的认证方式,只需提供用户名密码即可,但由于有把用户名密码暴露给第三方客户端的风险,在生产环境下被使用的越来越少.因此,在开发对外开放的RESTful API时,尽量避免采用HTTP Basic Auth OAuth OAuth(开放授权)是一个开放的授权标准,允许用户让

[CentOS 7系列]使用密钥认证机制远程登录

当服务器操作系统没有配置远程密钥认证时,默认需要手动输入密码口令. 以下用putty为例: 1.使用putty远程ssh登录192.168.137.100这台主机 2.第一次登录选择"是(Y)",信任该主机,缓存该主机登录信息. 3.登录时,要输入正确的账户和口令,才能正常登录该主机. 下面使用putty和xshell演示如何使用密钥机制远程登录: 一.使用putty密钥认证机制登录 1.打开putty安装目录中的putty key generator软件,点击"Genera