新年10个Flag实现中~
访问量
645.3K
文章数
124
运行天
760
一、引言1.1问题的引入客户端A、B、C都想要下载服务器S的某个文件,但文件传输过程中会经过许多不可靠的节点,应该如何保证A、B、C的请求不被篡改,且保证A、B、C收到的是没有被篡改的文件呢?1.2第一次解决——加密服务器S做了一对密钥,私钥自己保留,并把公钥发送给客户端A、客户端B、客户端C保存。这样,客户端A可以用公钥对请求进行加密,密文为““&A2*XVqzp346(??=””;服务器S收到后用私钥解密,明文为“客户端A想要下载资源文件”;中间节点没有私钥,无法解密这个请求,也就无法篡改了。此时,服务器S需要把资源文件传给客户端A,需要保证安全性,于是服务器S决定使用“数字签名(DigitalSignature)”:将资源文件用Hash函数生成“摘要(Digest)”,然后用私
前言各大浏览器、操作系统都屏蔽掉了SSLv2.0、SSLv3.0,原因是“不安全”,我们来分析SSLv3.0为什么不安全。一、POODLE简介2014年9月Google的一份研究报告《ThisPOODLEBites:ExploitingTheSSL3.0Fallback》指出,SSL存在安全漏洞CVE­-2014-3566,代号为POODLE(PaddingOracleOnDowngradedLegacyEncryption,基于降级旧加密协议的填充提示),该漏洞可以使得攻击者获取到一段明文数据,比如HTTP的cookie,且除了完全禁用SSL,或者利用TLS_FALLBACK_SCSV字段禁止协议降级到SSL,没有其他更好的手段可以防御。二、PaddingOracle攻击原理Padding
一、SSL/TLS发展历史SSL(SecureSocketLayer,安全套接层)v1.0最早于由网景公司(Netscape,以浏览器闻名)在1994年提出,该方案第一次解决了安全传输的问题。1995年公开发布了SSLv2.0,该方案于2011年被弃用(RFC6176-ProhibitingSecureSocketsLayer(SSL)Version2.0)。1996年发布了SSLv3.0(2011年才补充的RFC文档:RFC6101-TheSecureSocketsLayer(SSL)ProtocolVersion3.0),被大规模应用,于2015年弃用(RFC7568-DeprecatingSecureSocketsLayerVersion3.0)。这之后经过几年发展,于1999年被IE
前言了解TCP的KeepAlive机制有利于服务器调参。TCP的KeepAlive没错,和想象的一样,通过“心跳包”来检查链路是否连通,但在标准的TCP规范中,并没有保活的强制性要求。传输层KeepAilve缺点在传输层做保活有很多缺点:(1)如果中间链路出现短暂的差错(比如某个路由器重启),可能会使得一个非常好的链路被释放掉(2)心跳包耗费了不必要的带宽,增加了流量费用(3)在一些复杂的网络环境下(比如某些网络不响应不带数据的报文),TCP保活机制可能会失效。TCP的KeepAlive机制描述但事实上,许多实现都提供了KeepAlive的功能(默认关闭)。  如果一个给定的连接在7200秒(2小时)内没有任何动作,那么服务器就向客户端发送一个探查报文段,此时客户机可能处
一、通信协议的详细方案前文说到,我们设计了这么一个BTP(BWBTransportProtocol)通信协议:序号BTP字段名占用空间说明 1协议标识1字节 0x42(大写的'B') 2协议版本1字节 0x01(1.0版本) 3包类型1字节 握手请求包:0x01 握手响应包:0x02 心跳请求包:0x03 心跳响应包:0x04 数据包:0x05 断开请求包:0x06 断开响应包:0x07 4包序号1字节 0x00~0xFF循环使用 5数据长度2字节 0x0000~0xFFFF 6数据0~65535字节 要传输的数据
一、通信协议的设计说到通信,我们肯定会想到OSI七层模型,想到TCP/IP,想到Socket。但是如果我们需要直接和物理设备通信,尤其是对实时性、安全性要求较高的时候,采用在数据链路层发送自己设计的裸包的方法是最好不过的了:第一,安全性可控。自己设计的通信协议当然可以控制想要加密什么东西了。第二,实时性。不需要经过高层的封包解包,直接向MAC地址发送裸包。第三,也是最重要的,可裁剪。我们可以裁剪掉不需要的功能,增加需要的功能,这对于有内存闪存大小限制的嵌入式设备是很有意义的。那么,该如何去设计这个通信协议呢?最简单的协议可以考虑这些内容:序号协议字段名详细描述 1协议标识 标记这个包是用的你的协议 2协议版本 当协议有多个版本后,可以协调兼容问题&nb
1