网络安全的第一道防线：深入探索sslscan在SSLTLS证书安全检测中的原理与实践

本文链接：https://blog.csdn.net/ZL_1618/article/details/140684131

一、前言

sslscan
用于扫描SSL/TLS证书并报告协议版本、密码套件、密钥交换、签名算法和证书详细信息等，帮助用户从安全角度加强数据传输安全性，同时，sslscan还可以将结果输出到XML文件中，以便外部程序使用。本文将详细介绍sslscan用法案例及其扫描原理。

终端输出的颜色编码及其含义：

颜色	密码套件
红色背景	空套件
红色字体	破损套件（<=40 bit）、破损协议（SSLv2/SSLv3）或破损证书的签名算法（MD5）
黄色字体	弱密码套件（<=56 bit或RC4）或弱证书签名算法（SHA-1）
紫色字体	匿名套件（ADH或AECDH）

TLS协商过程

![img](https://img-
blog.csdnimg.cn/img_convert/f07a69bf20881e790b5824dc143434ec.png)

在TCP三次握手后的TLS握手阶段（即淡黄色部分）即为我们重点关注和检测的部分。

所在层级

![img](https://img-
blog.csdnimg.cn/img_convert/8e451a7b2c6f917fcc51ce10bf8382fb.png)

TLS 命名为安全传输层协议（ Transport Layer Security
），实际作用在传输层偏上的会话层，它既不影响上层协议又能保证上层协议的网络通信安全。

二、安装

sslscan在各大发行版的软件源中几乎都有，可以直接从软件源安装：

发行版	安装命令
ArchLinux	pacman -Sy sslscan
Centos/Redhat	yum install sslscan -y
Debian/Ubuntu	apt install sslscan -y
Gentoo	emerge --ask sslscan

也可以将源码git clone到本地进行编译安装：

代码语言：bash

复制

$ git clone https://github.com/rbsec/sslscan
$ cd sslscan
$ make static
$ ./sslscan --version

三、输出结构

不加任何参数的情况下，直接执行sslscan <目标>进行扫描，会完整的将各个部分展示到结果上。

各部分的输出含义如下：

区域	原文	含义
第一部分	SSL/TLS Protocols	支持的SSL/TLS版本
第二部分	TLS Fallback SCSV	是否支持TLS Fallback SCSV
第三部分	TLS renegotiation	是否支持TLS重协商
第四部分	TLS Compression	是否支持TLS压缩
第五部分	Heartbleed	是否存在心脏滴血漏洞
第六部分	Supported Server Cipher(s)	服务端支持的加密套件
第七部分	Server Key Exchange Group(s)	服务端支持的密钥交换组
第八部分	SSL Certificate	证书详细信息

以下面这段输出为例：

代码语言：bash

复制

$ sslscan www.google.com
Version: 2.1.2-static
OpenSSL 3.0.12 24 Oct 2023

Connected to 172.217.27.4

Testing SSL server www.google.com on port 443 using SNI name www.google.com

  SSL/TLS Protocols:  # 第一部分
SSLv2     disabled
SSLv3     disabled
TLSv1.0   enabled
TLSv1.1   enabled
TLSv1.2   enabled
TLSv1.3   enabled

  TLS Fallback SCSV:  # 第二部分
Server supports TLS Fallback SCSV

  TLS renegotiation:  # 第三部分
Secure session renegotiation supported

  TLS Compression:    # 第四部分
Compression disabled

  Heartbleed:         # 第五部分
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed
TLSv1.1 not vulnerable to heartbleed
TLSv1.0 not vulnerable to heartbleed

  Supported Server Cipher(s):  # 第六部分
Preferred TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve 25519 DHE 253
...略

  Server Key Exchange Group(s):  # 第七部分
TLSv1.3  128 bits  secp256r1 (NIST P-256)
TLSv1.3  128 bits  x25519
TLSv1.2  128 bits  secp256r1 (NIST P-256)
TLSv1.2  128 bits  x25519

  SSL Certificate:              # 第八部分
Signature Algorithm: sha256WithRSAEncryption
ECC Curve Name:      prime256v1
ECC Key Strength:    128

Subject:  www.google.com
Altnames: DNS:www.google.com
Issuer:   GTS CA 1C3

Not valid before: Dec 11 08:10:00 2023 GMT
Not valid after:  Mar  4 08:09:59 2024 GMT

四、用法案例及参数说明

需要注意，sslscan的所有参数选项必须写在被扫描的目标主机之前，不能写在后面，否则会报错，目前最新2.0版本是这样，后续随着版本更新可能有所优化。

正确示例：

代码语言：bash

复制

sslscan --show-certificate google.com

错误示例：

代码语言：bash

复制

sslscan google.com --show-certificate

1.扫描支持的SSL/TLS版本、cipher信息等

在**『输出结构』**中说过，不加任何参数的情况下，sslscan会显示总共八部分的内容。

同时，需要注意：

目标可以是域名、IP；
不指定端口的情况下默认为443，如需指定自定义端口，接:port即可，比如domain.com:8443；
输出结果中的服务端支持的加密套件(Supported Server Cipher(s))，Prefereed 表示优先选中的套件，Accepeted 表示支持的套件；
SSL/TLS等级和安全性：TLSv1.3 > TLSv1.2 > TLSv1.1 > TLSv1.0 > SSLv3 > SSLv2。

如果此时已经满足需求，则无需加任何多余的参数：

代码语言：bash

复制

sslscan <目标>

![img](https://img-
blog.csdnimg.cn/img_convert/e8aeab24512c7437f0458dc365603f17.png)

2.检测OCSP的状态（–ocsp）

1）CRL和OCSP

在此之前，首先了解下什么是CRL 。CRL （Certificate Revocation List）证书吊销列表是[RFC
5280](https://cloud.tencent.com/developer/tools/blog-
entry?target=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5280&source=article&objectId=2383594)定义的检查证书状态的机制。

想象一种场景，客户端通过SSL/TLS连接到服务端，怎么确保证书本身是否可靠安全？比如证书是否由于各种原因被证书申请者申请在证书有效期内提前吊销证书或安全原因被机构主动吊销（比如泄漏私钥的场景）？

首先每个证书颁发机构会维护并持续更新的一个已吊销的证书列表，任何想验证证书是否被吊销的用户都能下载此列表，如果列表中有你要被验证的证书，说明证书已经被吊销了，不再安全可信。

随着证书越来越多，CRL文件也愈来愈冗长，所以也会导致一些问题：

CRL列表随着被吊销的证书日益增多而变得冗长，每个客户端都必须取得包含所有证书序列号的CRL完整列表；
刚被吊销的证书，CRL列表更新并不及时，比如客户端已经缓存了CRL的场景，在缓存期内，证书会被认为一直有效。

基于上面两个历史原因，在[RFC 2560](https://cloud.tencent.com/developer/tools/blog-
entry?target=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc2560&source=article&objectId=2383594)又推出了OCSP
（Online Certificate Status
Protocol）在线证书状态协议，可以完美解决上面两个问题，首先支持实时检查证书状态的机制，并且支持查询需要被验证的证书序列号是否有效，而无需像CRL一样将整个CRL列