Server Name Indication(SNI),HTTP/TLS握手过程解析

这篇具有很好参考价值的文章主要介绍了Server Name Indication(SNI),HTTP/TLS握手过程解析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Server Name Indication(SNI)是一种TLS扩展,用于在TLS握手过程中传递服务器的域名信息。在未使用SNI之前,客户端在建立TLS连接时只能发送单个IP地址,并且服务器无法知道客户端请求的具体域名。这导致服务器需要使用默认证书进行握手,无法正确选择合适的证书。

使用SNI扩展后,客户端在发送ClientHello消息时会包含所请求的服务器的域名。服务器根据该域名来选择对应的证书进行握手,从而实现了多个域名共享同一个IP地址并使用不同证书的能力。

SNI对于虚拟主机或者CDN等场景特别有用,因为这些场景下,多个网站可能共享同一个IP地址。通过使用SNI,服务器能够正确地选择与域名匹配的证书,提高了安全性和灵活性。

SNI产生解决什么问题

Server Name Indication(SNI)的产生背景与互联网发展和IPv4地址短缺有关。

在互联网发展初期,每个网站通常拥有自己独立的IP地址。但随着网站数量的迅速增长和IPv4地址资源的有限,IP地址短缺问题变得日益严重。

为了解决IPv4地址短缺问题,一种解决方案是引入虚拟主机技术。虚拟主机是指在同一台物理服务器上托管多个不同域名的网站。通过共享同一个IP地址,多个网站能够减少IP地址的使用,并降低运维成本。

然而,这种虚拟主机技术在使用TLS(Transport Layer Security)协议时遇到了问题。TLS协议是用于加密和保护网络通信的协议,它在握手过程中需要使用正确的证书来验证服务器身份。但在使用虚拟主机时,服务器无法根据传统的握手方式正确选择合适的证书,因为无法获知客户端请求的具体域名。

为了解决这个问题,SNI扩展被引入TLS协议中。它允许客户端在握手时发送所请求的服务器域名信息,使服务器能够正确选择并使用对应的证书,实现了多个域名共享同一个IP地址并使用不同证书的能力。SNI的引入为虚拟主机和CDN等场景提供了更好的支持,进一步促进了IPv4地址资源的有效利用。

抓包分析http握手过程

触发http请求

curl www.baidu.com

tcpdump抓包:

tcpdump -i any port 80 -nnnvvvv -w http.pcap

tls sni,C/C++,http,c++,c语言,网络协议,TLS
HTTP (Hypertext Transfer Protocol) 的握手过程如下:

  • 1.建立TCP连接:客户端通过向服务器发送一个SYN包来发起与服务器的TCP连接。

  • 2.服务器回应:服务器接收到客户端的SYN包后,返回一个SYN-ACK包,表示同意建立连接。

  • 3.客户端确认:客户端接收到服务器的SYN-ACK包后,发送一个ACK包给服务器,表示连接已建立成功。

  • 4.发送HTTP请求:客户端与服务器建立了TCP连接后,客户端可以发送HTTP请求。HTTP请求包括HTTP方法(GET, POST等)、URI(Uniform Resource Identifier)和HTTP协议版本等信息。

  • 5.服务器响应:服务器接收到HTTP请求后,根据请求的内容进行处理,并返回HTTP响应。HTTP响应包括响应状态码(例如200表示成功,404表示未找到等)、响应头和响应体等信息。

  • tls sni,C/C++,http,c++,c语言,网络协议,TLS

  • 6.关闭连接:客户端接收到服务器的HTTP响应后,根据需要继续发送其他请求,或者关闭TCP连接。

这是一个简化的HTTP握手过程,实际上还有更多的细节和可选项,例如在建立TCP连接时可能需要进行三次握手以确保连接的可靠性,还有可能使用持久连接(Keep-Alive)机制来减少握手的次数等。HTTP握手过程中的这些步骤保证了客户端和服务器之间的通信顺利进行,并确保数据在网络传输时的可靠性和完整性。
tls sni,C/C++,http,c++,c语言,网络协议,TLS抓包分析TLS握手过程

触发https请求

curl -k --insecure "https://www.baidu.com"
tcpdump -i any port 443 -nnnvvvv -w https.pcap

tls sni,C/C++,http,c++,c语言,网络协议,TLSWireShark抓包验证SNI:
tls sni,C/C++,http,c++,c语言,网络协议,TLS

TLS握手过程是一个复杂的过程,包括以下步骤:

  • 1.客户端发送ClientHello报文:客户端发送一个ClientHello报文,该报文包含客户端支持的协议版本、会话ID、密码组和压缩方法。客户端提交的ClientHello所包含的密码组是客户支持的密码算法列表(按优先级降序排列),压缩方法是客户支持的压缩方法列表。
  • 2.服务器返回ServerHello报文:服务器发送一个ServerHello报文,该报文包含服务器建议的协议版本、服务器选择的密码组和压缩方法,以及两个随机数:ClientHello.random和ServerHello.random。
  • 3.服务器返回CA证书和请求客户端证书:服务器发送自己的证书(Certificate),Certificate 报文包含一个X.509证书或者一条证书链。除了匿名DH之外的密钥交换方法都需要发送Certificate报文。如果服务器需要被认证的话,服务器会发送自己的证书。同时,服务器可能会发送一个ServerKeyExchange报文,例如当服务器没有自己的证书或者证书仅用于签名时。
  • 4.客户端提交证书并发送ClientKeyExchange报文:客户端将自己的证书上报给服务器,同时会发送一个ClientKeyExchange报文,该报文包含密钥协商后的秘钥给服务器。
  • 5.客户端验证服务器的证书:客户端会验证服务器的证书的有效性。如果服务器的证书是有效的,客户端会发送一个ChangeCipherSpec报文和一个EncryptedHandshake消息。
  • 6.服务器发送ChangeCipherSpec报文和EncryptedHandshake消息:服务器也会发送ChangeCipherSpec报文和EncryptedHandshake消息,表示握手协商已经完成。
  • 7.应用层面交互:完成握手协商后,客户端和服务器会开始进行应用层面的交互,通过之前协商的秘钥来加密通信内容。

以上就是TLS握手过程的详细步骤。

Linux C/C++解析 Server Name Indication(SNI)字段

这是一个类似tcpdump的程序,用于在实时或捕获的流量中打印TLS SNI和HTTP/1.1主机字段。

char *tls_ContentType(uint8_t n)
{
	switch (n) {
		/* 20*/
		case SSL3_RT_CHANGE_CIPHER_SPEC:
			return "change_cipher_spec";
		/* 21 */
		case SSL3_RT_ALERT:
			return "alert";
		/* 22 */
		case SSL3_RT_HANDSHAKE:
			return "handshake";
		/* 23 */
		case SSL3_RT_APPLICATION_DATA:
			return "application_data";
		default:
			return "UNKNOWN";
	}

	return "";
}

char *tls_AlertLevel(uint8_t n)
{
	switch(n) {
		/* 1 */
		case SSL3_AL_WARNING:
			return "warning";
		/* 2 */
		case SSL3_AL_FATAL:
			return "fatal";
		default:
			return "UNKNOWN";
	}

	return "";
}

char *tls_AlertDescription(uint8_t n)
{
	switch(n) {
		/* 0 */
		case SSL3_AD_CLOSE_NOTIFY:
			return "close_notify";
		/* 10 */
		case SSL3_AD_UNEXPECTED_MESSAGE:
			return "unexpected_message";
		/* 20 */
		case SSL3_AD_BAD_RECORD_MAC:
			return "bad_record_mac";
		case 21:
			return "decryption_failed_RESERVED";
		case 22:
			return "record_overflow";
		case 30:
			return "decompression_failure";
		case 40:
			return "handshake_failure";
		case 41:
			return "no_certificate_RESERVED";
		case 42:
			return "bad_certificate";
		case 43:
			return "unsupported_certificate";
		case 44:
			return "certificate_revoked";
		case 45:
			return "certificate_expired";
		case 46:
			return "certificate_unknown";
		case 47:
			return "illegal_parameter";
		case 48:
			return "unknown_ca";
		case 49:
			return "access_denied";
		case 50:
			return "decode_error";
		case 51:
			return "decrypt_error";
		default:
			return "UNKNOWN";
	}

	return "";
}

char *tls_HandshakeType(uint8_t n)
{
	switch(n) {
		/* 0 */
		case SSL3_MT_HELLO_REQUEST:
			return "hello_request";
		/* 1 */
		case SSL3_MT_CLIENT_HELLO:
			return "client_hello";
		/* 2 */
		case SSL3_MT_SERVER_HELLO:
			return "server_hello";
		/* 11 */
		case SSL3_MT_CERTIFICATE:
			return "certificate";
		/* 12 */
		case SSL3_MT_SERVER_KEY_EXCHANGE:
			return "server_key_exchange";
		/* 13 */
		case SSL3_MT_CERTIFICATE_REQUEST:
			return "certificate_request";
		/* 14 */
		case SSL3_MT_SERVER_DONE:
			return "server_hello_done";
		/* 15 */
		case SSL3_MT_CERTIFICATE_VERIFY:
			return "certificate_verify";
		/* 16 */
		case SSL3_MT_CLIENT_KEY_EXCHANGE:
			return "client_key_exchange";
		/* 20 */
		case SSL3_MT_FINISHED:
			return "finished";
		default:
			return "UNKNOWN";
	}

	return "";
}
...
int tls_set_callback_handshake_clienthello_servername(
	int (*handler)(uint8_t *, uint16_t));
int tls_process_Handshake_ClientHello_Extensions_ServerName();
int tls_process_Handshake_ClientHello_Extensions();
int tls_process_Handshake_ClientHello();
uint32_t tls_process_record(uint8_t *payload, uint32_t payload_length);
int http_set_callback_request_host(int (*handler)(
	uint8_t *host_name, uint16_t host_name_length));
int http_init();
uint16_t http_process_request(uint8_t *payload, uint16_t payload_length);
void http_cleanup();
int sni_handler (uint8_t *host_name, uint16_t host_name_length);

int main (int argc, char *argv[])
{
...

	while ((i = getopt(argc, argv, "hf:pi:r:w:")) != -1) {
		switch(i) {
			case 'h':
				fprintf(stderr,
					"Use: %s [-h] [-f bpf] [-p] -i interface [-w dump.pcap]\n", argv[0]);
				fprintf(stderr,
					"Use: %s [-h] [-f bpf] [-p] -r trce.pcap [-w dump.pcap]\n", argv[0]);
				return -1;
				break;
			case 'f':
				bpf_s = optarg;
				opt_flags |= OPT_BPF;
				break;
			case 'p':
				opt_flags |= OPT_PROMISCUOUS;
				break;
			case 'i':
				device_name = optarg;
				opt_flags |= OPT_DEVICE;
				break;
			case 'r':
				trace_fname = optarg;
				opt_flags |= OPT_TRACE;
				break;
			case 'w':
				dump_fname = optarg;
				opt_flags |= OPT_DUMP;
				break;
			default:
				break;
		}
	}

...

	fprintf(stdout, "[*] PID: %u\n", getpid());

	if (opt_flags & OPT_DEVICE) {
		fprintf(stdout, "[*] Device: '%s'\n", device_name);
		fprintf(stdout, "[*] Promiscuous: %d\n", PROMISCUOUS);

		if (!(pcap_handle =
			pcap_open_live(device_name, SNAPLEN, PROMISCUOUS, PCAP_TIMEOUT,
			errbuf))) {
			fprintf(stderr, "[FATAL] %s\n", errbuf);
			return -1;
		}
	}

	if (opt_flags & OPT_TRACE) {
		fprintf(stdout, "[*] Trace: '%s'\n", trace_fname);

		if (!(pcap_handle =
			pcap_open_offline(trace_fname, errbuf))) {
			fprintf(stderr, "[FATAL] %s\n", errbuf);
			return -1;
		}
	}

...
	if (!(opt_flags & OPT_BPF)) {
		bpf_s = bpf_default;
		opt_flags |= OPT_BPF;
	}

	fprintf(stdout, "[*] BPF: '%s'\n", bpf_s);

	if (pcap_compile(pcap_handle, &bpf, BPF, BPF_OPTIMIZE,
		PCAP_NETMASK_UNKNOWN) == -1) {
		fprintf(stderr, "[FATAL] Couldn't parse filter. %s\n",
			pcap_geterr(pcap_handle));
		pcap_close(pcap_handle);
		return -1;
	}

	if (pcap_setfilter(pcap_handle, &bpf) == -1) {
		fprintf(stderr, "[FATAL] Couldn't install filter. %s\n",
			pcap_geterr(pcap_handle));
		pcap_close(pcap_handle);
		return -1;
	}

	pcap_freecode(&bpf);

	pcap_dumper_handle = NULL;

	if (opt_flags & OPT_DUMP) {
		fprintf(stdout, "[*] Dump: '%s'\n", dump_fname);

		if (!(pcap_dumper_handle = pcap_dump_open(pcap_handle, dump_fname))) {
			fprintf(stderr, "[WARNING] Couldn't create dump file. %s\n",
				pcap_geterr(pcap_handle));
		}
	}
...

	tls_set_callback_handshake_clienthello_servername(&sni_handler);
	http_set_callback_request_host(&sni_handler);

	http_init();

	act.sa_handler = signal_handler;
	sigemptyset (&act.sa_mask);
	act.sa_flags = 0;

	if (sigaction(SIGINT, &act, NULL)) {
		perror("sigaction");
		fprintf(stderr,
			"[WARNING] Failed to set signal handler for SIGINT.\n");
	}

	if (sigaction(SIGTERM, &act, NULL)) {
		perror("sigaction");
		fprintf(stderr,
			"[WARNING] Failed to set signal handler for SIGTERM.\n");
	}

	if (sigaction(SIGSEGV, &act, NULL)) {
		perror("sigaction");
		fprintf(stderr,
			"[WARNING] Failed to set signal handler for SIGSEGV.\n");
	}

	fprintf(stderr, "Capturing ...\n");

	if (pcap_loop(pcap_handle, -1, &my_pcap_handler, NULL) == -1) {
		fprintf(stderr, "[FATAL] pcap_loop failed. %s\n",
			pcap_geterr(pcap_handle));
	}

	if (!(opt_flags & OPT_TRACE)) {
		if (pcap_stats(pcap_handle, &ps) == -1) {
			fprintf(stderr, "pcap_stats failed. %s\n", pcap_geterr(pcap_handle));
		} else {
			fprintf(stderr, "%u packets received\n", ps.ps_recv);
			fprintf(stderr, "%u packets dropped\n", ps.ps_drop + ps.ps_ifdrop);
		}
	}

	pcap_close(pcap_handle);

	http_cleanup();

	if (pcap_dumper_handle) {
		pcap_dump_close(pcap_dumper_handle);

		fprintf(stderr, "Written %s\n", dump_fname);
		if (!(opt_flags & OPT_DUMP)) {
			free(dump_fname);
		}
	}

...
}

If you need the complete source code, please add the WeChat number (c17865354792)

tls sni,C/C++,http,c++,c语言,网络协议,TLScurl触发SNI字段解析

curl -k --insecure "https://www.baidu.com"
curl www.baidu.com

该程序从TLS握手客户端Hello消息中提取服务器名称指示(SNI)字段(RFC 4366),并从HTTP/1.1请求中提取主机请求头字段(RFC 2616)。

它接受一个网络接口作为输入来监控其流量(可选地以混杂模式),或者接受一个PCAP文件作为输入来读取。默认情况下,它使用BPF以目标端口为80或443的TCP数据包为目标,但如果相应配置,它将处理其他端口上的TLS和HTTP数据包以及UDP数据包。捕获的流量可以保存到PCAP文件中。

总结

SNI,即服务器名称指示,是TLS协议的扩展。它允许在握手过程开始时通过客户端告诉服务器正在连接的主机名称,从而解决一个服务器拥有多个域名的情况。

在TLS握手信息中并没有携带客户端要访问的目标地址,导致当一台服务器有多个虚拟主机,且每个主机的域名不一样,使用了不一样的证书时,不知道和哪台虚拟主机进行通信。而SNI允许Web服务器通过SSL或TLS握手的扩展在单个IP地址上托管多个站点,从而使得HTTPS网站具有唯一的TLS证书,即使它们位于共享IP地址上。使用SNI时,服务器的主机名包含在TLS握手中,这使得HTTPS网站具有唯一的TLS证书,即使它们位于共享IP地址上也是如此。

Welcome to follow WeChat official account【程序猿编码

参考:RFC 4366、RFC 2616文章来源地址https://www.toymoban.com/news/detail-762140.html

到了这里,关于Server Name Indication(SNI),HTTP/TLS握手过程解析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 深入解析:HTTP和HTTPS的三次握手与四次挥手

    推荐阅读 字数统计:约 571 字 预计阅读时间:约 3 分钟 引言 在网络通信中,HTTP和HTTPS是两个最为常见的协议,它们作为应用层协议,扮演着浏览器与服务器之间传输数据的关键角色。而在建立和终止网络连接时,三次握手和四次挥手是不可或缺的步骤。本文将深入解析HTT

    2024年02月12日
    浏览(41)
  • unable to connect to the server: net/http: tls handshake timeout已解决

    在自己电脑上学习k8s,使用kind安装了一个集群,过了一段时间再打开发现了一个问题。 执行 kubectl get po 的时候有报错 查了半个小时也没解决,有说内存不够,也有说要重启服务的,也有说重启docker的,关闭交换分区的,还有代理不对什么的,都没有解决我的问题,最后我试

    2024年02月13日
    浏览(54)
  • kubectl 执行时报错:Inable to connectto the server: net/http: TLs handshake timeout

    Inable to connectto the server: net/http: TLs handshake timeout 问题排查 这个错误通常表示客户端无法与服务器建立 TLS 握手,可能的原因包括服务器证书无效、网络问题或代理设置等。 以下是一些可能的解决方法: 1. 检查证书是否有效:在某些情况下,TLS 握手失败可能是由于证书过期、

    2024年02月11日
    浏览(39)
  • HTTP协议 和 HTTPS协议的区别(4点) && HTTPS的缺点 && HTTP如何使用SSL/TLS协议加密过程 && CA证书干啥的

      1. HTTP协议的端口号是80, HTTPS协议的端口号是443 2. HTTP协议使用的URL是以 http:// 开头,HTTPS协议使用的URL是以https://开头 3. HTTP协议和HTTPS协议最主要的区别是: HTTP协议所生成的HTTP请求报文被TCP协议 以明文形式透明传输,同时 客户端与服务器之间无法核验对方的身份(不晓

    2024年02月14日
    浏览(46)
  • HTTP协议 和 HTTPS协议的区别(4点) && HTTPS如何使用SSL/TLS协议加密过程 && CA证书干啥的

      1. HTTP协议的端口号是80, HTTPS协议的端口号是443 2. HTTP协议使用的URL是以 http:// 开头,HTTPS协议使用的URL是以https://开头 3. HTTP协议和HTTPS协议最主要的区别是: HTTP协议所生成的HTTP请求报文被TCP协议 以明文形式透明传输,同时 客户端与服务器之间无法核验对方的身份(不晓

    2024年02月14日
    浏览(43)
  • https 中 ssl/tls 的握手

    如果使用了 https 协议,那么在建立 tcp 连接之后,还会进行 tls 握手。也就是 https 的证书验证和密钥传输的过程。简化的流程如下: 客户端发送请求 服务端返回证书 客户端验证证书,提取公钥,生成对称加密的密钥,用公钥加密后发送给服务端 服务端收到请求,用私钥揭秘

    2024年01月23日
    浏览(35)
  • 浅析 TLS(ECDHE)协议的握手流程(图解)

    通过 wireshark 抓取 HTTPS 包,理解 TLS 1.2 安全通信协议的握手流程。 重点理解几个点: TLS 握手流程:通过 wireshark 抓取 HTTPS 包理解。 协商加密:双方通过 ECDHE 椭圆曲线的密钥交换算法,协商出共享的 会话密钥 进行内容对称加密通信,避免传输会话密钥被中间人窃取。 CA 证

    2024年02月07日
    浏览(47)
  • 全网多种方法分析解决HTTP Status 404资源未找到的错误,TCP的3次握手,dns域名解析,发起http请求以及cookie和session的区别

    正赶上最近 ChatGPT 很火,于是借助 ChatGPT 来解释 HTTP Status 404 ,如下所示: HTTP Status 404: The HTTP Status 404 means that the requested resource was not found on the server. This is commonly used in response to a failed HTTP request and can be caused by mistyping an URL, spelling mistakes, or trying to access a file or resource that

    2023年04月08日
    浏览(42)
  • 4.14 HTTPS 中 TLS 和 TCP 能同时握手吗?

    目录 实现HTTPS中TLS和TCP同时握手的前提: 什么是TCP Fast Open? TLS v1.3 TCP Fast Open + TLSv1.3 HTTPS都是基于TCP传输协议实现的,得先建立完可靠得TCP连接才能做TLS握手的事情。 1、客户端和服务端开启了TCP Fast Open,且TLS版本在1.3; 2、客户端和服务端已经完成过一次通信。 常规的T

    2024年02月11日
    浏览(28)
  • 详解gmssl和tls1.2握手流程分析及接口实现

    通过阅读openssl源码具体分析ssl握手中的报文交互流程,包括发送和处理每个报文所做的主要事情。同时分析ssl协议中的一些主要问题,包括tls和gmssl的区别、单向认证和双向认证、两种会话复用方式对比,调用openssl接口实现ssl客户端和服务端之间的通信。 注意: TLS1.2中密钥

    2024年02月10日
    浏览(31)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包