Linux网络应用层协议之http/https

文章目录

目录

一、http协议

1.URL

2.http协议格式

3.http的方法

4.http的状态码

5.http常见header

6.实现一个http服务器

二、https协议

1.加密

2.为什么要加密

3.常见的加密方式

对称加密

非对称加密

4.https的工作过程探究

方案1 只使用对称加密

方案2 只使用非对称加密

方案3 双方都使用非对称加密

方案4 非对称加密+对称加密

中间人攻击

引入证书

CA认证

方案5 非对称加密+对称加密+证书认证

https的整个工作流程

小结

总结

---

---

再谈协议

协议是一种"约定"，socket api的接口，在读写数据时，都是按照"字符串"的方式来发送接收的，如果要传输一些"结构化的数据"。在这种情况下，只要保证，一方发送时构造的数据，在另一端能够正确的进行解析。这种约定，就是应用层协议。

1.网络版本计算器例子

例如，现在要在服务器端实现一个加法器，客户端将要计算的两个数发送，然后由服务器进行计算，最后再把结果返回给客户端。

约定方案1：

• 客户端发送一个"1+2"的字符串
• 这个字符串中有两个操作数，都是政协
• 这两个数字之间会有一个字符 只能是"+"
• 数字和运算符之间没有空格

约定方案2：

• 定义结构体来表示我们要交互的信息
• 发送数据时候，将结构体按照一个规则转换成字符串，接收到数据再按照相同的规则把字符串转化为结构体
• 这个过程称为"序列化”和“反序列化"

typedef struct Request{
int a;
int b;
}Request;typedef struct Response
{int sum;}Response;// client.c 客户端核心代码
Request request;
Response response;scanf("%d,%d", &request.a, &request.b);
write(fd, request, sizeof(Request));
read(fd, response, sizeof(Response));// server.c 服务端核心代码
Request request;
read(client_fd, &request, sizeof(request));
Response response;
response.sum = request.a + request.b;
write(client_fd, &response, sizeof(response));

一、http协议

虽然应用层协议程序员可以自定义，但是有一些现成的又很好用的协议，http是超文本传输协议。

1.URL

平时，我们称呼的网址，就是url。如:

http://user:[e-mail]:80/dir/index.htm?uid=1#chi1

其中，http是协议方案名称，user:pass为登录信息，www.example.jp是ip,80是端口，/dir/index.htm?带层次的文件路径，uid=1查询字符串，#ch1片段标识符

其中，/ ? :这样的字符，以及被url当作特殊字符，因此这些字符不能随意出现。如果某个参数中，需要带这样的字符，就必须先对特殊字符进行转义

2.http协议格式

1）http请求

首行:【方法】+【URL]+【版本】

POST

HOST

connection

content-length

cath-control

origin

upgrade-insecure-requests

content-type

user-agent

accept

referer

accept-encoding

accept-language

cookie

2）http响应

首行: [版本号] + [状态码] + [状态码解释] Header: 请求的属性, 冒号分割的键值对;每组属性之间使用\n分隔;遇到空行表示Header部分结束

Body: 空行后面的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有一个

Content-Length属性来标识Body的长度; 如果服务器返回了一个html页面, 那么html页面内容就是在 body中

HTTP/1.1 200 OK

SERVER

CONTENT-TYPE

CONTENT-LANGUAGE

TRANSFER-ENCODING

DATE:

3.http的方法

方法	说明	支持的http协议版本
GET	获取资源	1.0，1.1
POST	传输实体主体	1.0，1.1
PUT	传输文件	1.0，1.1
HEAD	获得报文首部	1.0，1.1
DELETE	删除文件	1.0，1.1
OPTIONS	询问支持的方法	1.1
TRACE	追踪路径	1.1
CONNECT	要求用隧道协议连接代理	1.1
LINK	建立和资源之间的关系	1.0
UNLINE	断开连接关系	10

4.http的状态码

	类别	原因
1xx	Informational(信息性状态码）	接收的请求正在处理
2xx	SUCCESS	请求正常处理完毕
3xx	Redirection(重定向状态码）	需要进行附加操作完成请求
4xx	CLIENT ERROR(客户端错误状态码）	服务器无法处理请求
5xx	SERVER ERROR（服务器错误状态码）	服务器处理请求出错

200（ok),404(Not Found),403(FORBIDDEN),302(redirect），504（BAD GATEWAY）

5.http常见header

• CONTENT TYPE:数据类型（text,html)
• CONTENE LENGTH:body的长度
• Host:客户端告诉服务器，请求的资源在哪个主机的哪个端口
• User-Agent:声明用户的操作系统和浏览器版本信息
• referer：当前页面是从哪个页面跳转的
• location:搭配3xx状态码使用，告诉客户端接下来去哪里访问
• cookie：用于在客户端存储少量信息，通常用于实现会话session功能

6.实现一个http服务器

见gitee：地址https://gitee.com/a_young

二、https协议

https也是一个应用层协议，在http的基础上引入了一个加密层。

http协议都是按照文本的方式明文传输的，这就导致在传输过程中出现一些被篡改的情况。

1.加密

加密就是把明文（要传输的信息）进行一系列变换，生成密文

解密就是把密文再进行一系列变换，还原成明文

在这个加密和解密的过程中，往往需要一个或多个中间数据，辅助这个过程，这样的数据称为密钥。

2.为什么要加密

由于我们通过网络传输的任何数据包都会经过运营商的网络设备（路由器，交换机等），那么运营商的网络设备就可以解析出你传输数据的内容，并进行篡改。

比如，使用某款音乐app下载某首歌，此时点击下载按钮，其实就是给服务器发送了一个http请求，获取到的http响应其实就包含了该首歌的下载链接，运营商劫持之后，发现这个请求是下载歌，那么就自动将给用户的响应篡改，篡改成下载别的恶意软件的下载地址。

所以，因为http的内容是明文传输，明文数据通过路由器，wifi热点，通信服务运营商，代理服务器等多个节点，如果信息在传输过程中被劫持，传输的内容就完全被暴露，劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击，所以需要对信息进行加密。

3.常见的加密方式

对称加密

• 采用单钥密码系统的加密方法：同一个密钥可以同时用作对信息的加密和解密，这种加密方法称为对称加密，也成为单密钥加密，特征：加密和解密所用的密钥是相同的
• 常用的对称加密算法：DES,3DES,AES,TDEA,BLOWFISH,RC2等
• 特点：算法公开，计算量小，加密速度快，效率高
• 一个简单的对称加密，按位异或:

假设明文a = 1234，密钥key =8888

则加密a^key得到密文b为9834

然后针对密文9834再次b^key，得到原来的明文1234

非对称加密

需要两个密钥进行加密和解密，这两个密钥简称公钥和私钥

常见非对称加密算法：RSA,DAS,ECDSA

特点：算法强度复杂，安全性依赖于算法，但是算法过于复杂，解密速度没有对称加密解密的速度快

公钥和私钥是配对的，可以正，反两用，比如:

1.通过公钥对明文加密，变成密文；通过私钥对密文解密，变成明文

2.通过私钥对明文加密，变成密文；通过公钥对密文解密，变成明文

比如: A 要给 B ⼀些重要的⽂件, 但是 B 可能不在. 于是 A 和 B 提前做出约定:

B 说: 我桌⼦上有个盒⼦, 然后我给你⼀把锁, 你把⽂件放盒⼦⾥⽤锁锁上, 然后我回头拿着钥匙来开锁 取⽂件。

在这个场景中, 这把锁就相当于公钥, 钥匙就是私钥. 公钥给谁都⾏(不怕泄露), 但是私钥只有 B ⾃⼰持 有. 持有私钥的⼈才能解密。

4.https的工作过程探究

方案1 只使用对称加密

  如果通信双方各自持有一个密钥x，且没有别人知道，这两方的通信安全当然可以被保证（除非密钥被破解）。引入对称加密，即使数据被截获，但是黑客不知道密钥，因此无法进行解密，也就不知道请求。但是实际上，服务器同一时刻其实是给很多客户端提供的，客户端每个人的密钥都必须是不同的（如果相同就很容易扩散，黑客可以轻易获取），因此服务器就需要维护每个客户端和每个密钥之间的关联联系，这也是很费事的事情。

  比较理想的做法，就是在客户端和服务器建立连接的时候，双方协商确定这次的密钥，但是如果将密钥明文传输，那么黑客也就可以获得密钥，此后的加密操作没有意义。

  因此密钥也需要加密传输，但是这就形成了一个先有鸡还是先有蛋的问题，密钥的密钥......

方案2 只使用非对称加密

  鉴于非对称加密的机制，如果服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传输数据前都先用这个公钥加密好再传，从客户端到服务器信道似乎是安全的（实际有安全问题），只有服务器有相应的私钥能解开公钥加密的数据。

  如果服务器用它的私钥加密数据传输给浏览器，那么浏览器用公钥可以解密，二这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持，那么它也能用该公钥解密服务器传来的信息了。

方案3 双方都使用非对称加密

1. 服务端拥有公钥S与对应的私钥S'，客⼾端拥有公钥C与对应的私钥C'

2. 客⼾和服务端交换公钥

3. 客⼾端给服务端发信息：先⽤S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥 S'

4. 服务端给客⼾端发信息：先⽤C对数据加密，在发送，只能由客⼾端解密，因为只有客⼾端有私钥 C'

这样貌似也⾏啊，但是 效率太低  依旧有安全问题

方案4 非对称加密+对称加密

先解决效率问题

• 服务器端具有非对称公钥S和S'
• 客户端发起https请求，获取服务器端公钥S
• 客户端在本地生成对称密钥C，通过公钥S加密，发送给服务器
• 中间的网络设别没有私钥，即使截获了数据，也无法还原出内部的原文，也就无法获取到对称密钥
• 服务器通过私钥s'还原出客户端发送的对称密钥C,并且使用这个对称密钥加密给客户端返回的响应数据
• 后续客户端和服务器之间的通信都使用对称加密即可，由于该密钥只有客户端和服务器两个主句知道，其他主机和设备不知道密钥即使截获也没有意义
• 这个方案仍旧有一个问题：如果中间网络一开始就攻击

中间人攻击

• 服务器具有非对称加密算法的公钥S，私钥S'
• 中间人具有非对称加密算法的公钥M，私钥M'
• 客户端向服务器发起请求，服务器明文传送公钥S给客户端
• 中间人劫持数据报文，提取公钥S并且保存，然后将劫持报文中的公钥S替换成自己的公钥M，并伪造报文发送给客户端
• 客户端收到报文，提取报文M（客户端此时不知道公钥被替换），自己形成对称密钥X，用公钥M加密X，形成报文发送给服务器
• 中间人劫持后，直接用私钥M'解密，得到通信密钥X，再用曾经保存的服务端公钥S加密后，将报文推送给服务器
• 服务器拿到报文，用自己的私钥S'解密，得到通信密钥X
• 双方开始采用X进行对称加密，进行通信。但是一切都在中间人的视角内进行。
• 这个方案的本质问题就是，客户端无法确定收到含有公钥的数据报文，就是目标服务器发送过来的。

引入证书

CA认证

服务端在使用HTTPS之前，需要向CA机构申请一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传给浏览器，浏览器从证书里获得公钥即可。证书就如身份证，证明服务端公钥的权威性。

这个证书可以理解成一个结构化的字符串，里面包含了一下信息：证书发布机构，证书有效期，公钥，证书所有者，签名，...

申请证书的时候，需要在特定平台生成，同时生成一对密钥，即公钥和私钥

方案5 非对称加密+对称加密+证书认证

https的整个工作流程

客户端建立https请求，服务器端确认加密，返回客户端数字证书。

客户端证书合法校验，如果非法，进行提示，如果合法，随机生成密钥R，用证书中的公钥加密R

客户端向服务端传送加密后的R，服务器收到后进行解密，获取R，使用R加密网页内容，返回加密的网页内容，客户端使用R解密网页内容。

小结

https工作过程中涉及到的密钥有三组：

第一组：非对称加密 用于校验证书是否被篡改，服务器持有私钥（私钥在形成CSR文件与申请证书时获得），客户端持有公钥（OS包含可信任的CA认证机构有哪些，同时持有对应公钥），服务器在客户端的请求后，返回携带签名的证书，客户端通过这个公钥进行验证，保证证书的合法性，确认服务端公钥的权威性

第二组：非对称加密 用于协商生成对称加密的密钥，客户端收到ca中的公钥是被信任的，给随机生成的对称加密的密钥加密，传输给服务器，服务器通过私钥获取多对称加密密钥

第三组：对称加密：客户端和服务器后续的传输过程都通过对称密钥加密解密

---

总结