Brotli压缩

Brotli是一种全新的数据格式,可以提供比Zopfli20-26%的压缩比。据谷歌研究,Brotli压缩速度同zlibDeflate实现大致相同,而在Canterbury语料库上的压缩密度比LZMAbzip2略大。

链接:Google开源Brotli压缩算法

微软使用了一种基于谷歌提供的C代码的实现,向.NET Core 2.1添加了Brotli压缩支持。由于Brotli得到了许多Web浏览器和Web服务器的广泛支持,所以.NET Core提供对这项技术的支持是非常有用的。

什么是 Brotli 压缩算法
Brotli最初发布于2015年,用于网络字体的离线压缩。Google软件工程师在2015年9月发布了包含通用无损数据压缩的Brotli增强版本,特别侧重于HTTP压缩。其中的编码器被部分改写以提高压缩比,编码器和解码器都提高了速度,流式API已被改进,增加更多压缩质量级别。新版本还展现了跨平台的性能改进,以及减少解码所需的内存。

与常见的通用压缩算法不同,Brotli使用一个预定义的120千字节字典。该字典包含超过13000个常用单词、短语和其他子字符串,这些来自一个文本和HTML文档的大型语料库。预定义的算法可以提升较小文件的压缩密度。

使用brotli替换deflate来对文本文件压缩通常可以增加20%的压缩密度,而压缩与解压缩速度则大致不变。使用Brotli进行流压缩的内容编码类型已被提议使用“br”。

Brotli 的实际压缩效果,需要根据需要来具体分析,目前并不是每个网站都有较好的加速效果,另外,目前仅仅被限制在HTTPS上,HTTP是不支持的。

ubuntu 20.04 系统上自带的 apache 2.4.41 上启用 brotli 压缩算法的方式如下:

$ sudo apt-get install brotli

$ sudo a2enmod brotli

Apache 2 的配置文件增加 brolti 的配置信息,如下:

<VirtualHost 1.2.3.4:443>

    DocumentRoot /var/www/
    ServerName example.com

    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf

    CustomLog /var/log/apache2/example.com.access.log common
    ErrorLog /var/log/apache2/example.com.error.log

    <IfModule mod_brotli.c>
      SetOutputFilter BROTLI_COMPRESS;DEFLATE

      BrotliCompressionQuality  6
      BrotliCompressionWindow 18

      AddOutputFilterByType BROTLI_COMPRESS text/html
      AddOutputFilterByType BROTLI_COMPRESS text/plain
      AddOutputFilterByType BROTLI_COMPRESS text/xml
      AddOutputFilterByType BROTLI_COMPRESS text/css
      AddOutputFilterByType BROTLI_COMPRESS text/javascript
      AddOutputFilterByType BROTLI_COMPRESS application/x-javascript
      AddOutputFilterByType BROTLI_COMPRESS application/javascript
      AddOutputFilterByType BROTLI_COMPRESS application/json
      AddOutputFilterByType BROTLI_COMPRESS application/x-font-ttf
      AddOutputFilterByType BROTLI_COMPRESS application/vnd.ms-fontobject
      AddOutputFilterByType BROTLI_COMPRESS image/x-icon
    </IfModule>

</VirtualHost> 

重启服务,如下:

$ sudo systemctl restart apache2.service

测试结果

$ curl -I -H 'Accept-Encoding: br' https://www.mobibrw.com
HTTP/1.1 200 OK
Date: Wed, 10 Feb 2021 01:17:49 GMT
Server: Apache
Vary: Accept-Encoding,Cookie
Cache-Control: max-age=3, must-revalidate
Upgrade: h2
Connection: Upgrade
Last-Modified: Wed, 10 Feb 2021 01:16:24 GMT
Content-Encoding: br
Content-Length: 1
Content-Type: text/html; charset=UTF-8

参考链接


SSL相关漏洞解决方法

本次涉及漏洞

1.漏洞名称:SSL 3.0 POODLE攻击信息泄露漏洞(CVE-2014-3566)【原理扫描】

2.SSL/TLS 受诫礼(BAR-MITZVAH)攻击漏洞(CVE-2015-2808)【原理扫描】

 

知识普及1:SSL协议要点

SSL(Secure Sockets Layer 安全套接层)是一种基于Web应用的安全通信协议,最早由Netscape(网景)公司提出。SSL介于TCP协议和应用层协议之间,主要作用就是将HTTP、FTP等应用层的数据进行加密然后依托可靠的TCP协议在互联网上传输到目的地,其中最典型的应用就是https。

SSL提供3个基本的安全服务:

1)身份合法性:数据发送方和接收方要确认彼此身份,要确保各自的身份不会被冒充。

2)数据机密性:所有传输的数据都进行加密,并且要确保即使数据被截获也无法破解。

3)数据完整性:确保收到的数据与发送方发出的数据一致,没有被篡改。

SSL协议主要采用的数据加密算法:

1)非对称加密算法:数据加密和解密使用不同的密钥,如RSA公钥加密算法。优点是安全级别高,很难被破解;缺点是加密解密的速度慢,因此只适用于小量数据的加密。SSL协议采用非对称加密算法实现数字签名,验证数据发送方(或接收方)的身份,同时也用非对称加密算法交换密钥(用于数据加密的对称加密算法的密钥,以及用于数据完整性验证的MAC算法)。

2)对称加密算法:数据加密和解密使用同一个密钥,如DES、3DES、RC4等都是对称加密算法。优点是加解密速度快,适用于大数据量的加密,但安全性较差。SSL协议采用对称加密算法对传输的数据进行加密。

3)MAC算法:Message Authentication Codes,即消息认证码算法,MAC含有密钥散列函数算法,兼容了MD和SHA算法的特性,并在此基础上加入了密钥。SSL协议采用MAC算法来检验消息的完整性。

 

知识普及2:SSL协议的版本

目前在用的SSL协议主要有5个版本,分别是SSL2.0、SSL3.0、TLS1.0、TLS1.1和TLS1.2,这里的TLS(Transport Layer Security,传输层安全)协议是SSL协议的升级版。

在SSL协议曝出Poodle漏洞后,微信公众平台将取消对SSLv2、SSLv3两个版本的支持,浏览器及其他采用SSL协议的平台也会逐渐取消对SSLv2、SSLv3的支持,目前只建议使用TLSv1.0、TLSv1.1和TLSv1.2三个版本。

 

1.漏洞名称:SSL 3.0 POODLE攻击信息泄露漏洞(CVE-2014-3566)【原理扫描】

涉及设备漏洞服务

 此次设备受此漏洞波及影响主要是因为上述系统部署了Tomcat 的https服务,而Tomcat https服务默认情况下支持SSL 3.0协议(目前在用的SSL协议主要有5个版本,分别是SSL2.0、SSL3.0、TLS1.0、TLS1.1和TLS1.2.SSL3.0是已过时且不安全的协议,目前已被TLS 1.0,TLS 1.1,TLS 1.2替代)

漏洞描述和利用

SSL3.0是已过时且不安全的协议,目前已被TLS 1.0,TLS 1.1,TLS 1.2替代,因为兼容性原因,大多数的TLS实现依然兼容SSL3.0。

为了通用性的考虑,目前多数浏览器版本都支持SSL3.0,TLS协议的握手阶段包含了版本协商步骤,一般来说,客户端和服务器端的最新的协议版本将会被使用。其在与服务器端的握手阶段进行版本协商的时候,首先提供其所支持协议的最新版本,若该握手失败,则尝试以较旧的协议版本协商。能够实施中间人攻击的攻击者通过使受影响版本浏览器与服务器端使用较新协议的协商的连接失败,可以成功实现降级攻击,从而使得客户端与服务器端使用不安全的SSL3.0进行通信,此时,由于SSL 3.0使用的CBC块加密的实现存在漏洞,攻击者可以成功破解SSL连接的加密信息,比如获取用户cookie数据。这种攻击被称为POODLE攻击(Padding Oracle On Downgraded Legacy Encryption)。此漏洞影响绝大多数SSL服务器和客户端,影响范围广泛。但攻击者如要利用成功,需要能够控制客户端和服务器之间的数据(执行中间人攻击)。

继续阅读SSL相关漏洞解决方法

ubuntu 20.04 & ubuntu18.04快速开启TCP BBR实现高效单边加速

`Linux Kernel` 内核升级到 `4.9` 及以上版本可以实现 `BBR` 加速,由于`Ubuntu 18.04` 默认的内核就是 `4.15`版本的内核,由于`Ubuntu 20.04` 默认的内核就是 `5.4` 版本的内核,并已经默认编译了 `TCP BBR` 模块,所以可以直接通过参数开启。

新的 `TCP` 拥塞控制算法 `BBR` (Bottleneck Bandwidth and RTT) 可以让服务器的带宽尽量跑慢,并且尽量不要有排队的情况,让网络服务更佳稳定和高效。

修改系统变量:

$ echo 'net.core.default_qdisc=fq' | sudo tee -a /etc/sysctl.conf 

$ echo 'net.ipv4.tcp_congestion_control=bbr' | sudo tee -a /etc/sysctl.conf

保存生效

$ sudo sysctl -p

执行

$ sysctl net.ipv4.tcp_available_congestion_control

如果结果是这样

$ sysctl net.ipv4.tcp_available_congestion_control 
net.ipv4.tcp_available_congestion_control = bbr cubic reno

就开启了。 执行 lsmod | grep bbr ,以检测 BBR 是否开启。

一般建议重启系统,重启后执行

$ sysctl net.ipv4.tcp_congestion_control 
net.ipv4.tcp_congestion_control = bbr

参考链接


WOL网络唤醒在微星主板上开启(ubuntu 20.04/Windows 10双系统)

网络唤醒

微星H97I-AC的板子开启WOL网络唤醒

主板:微星 H97I-AC,集成 Realtek 千兆网卡,这个网卡自带网络唤醒功能,但是需要在操作系统中通过驱动开启这个功能,BIOS中无法直接开启。
操作系统:Windows 10/ubuntu 20.04双系统,双系统都需要进行配置,才能实现全部系统关机之后都能正常唤醒。

BIOS 设置

  1. 高级–整合周边设备–网卡ROM启动,设置为允许
  2. 高级–电源管理设置–Eup 2013,设置为禁止
  3. 高级–唤醒事件设置–PCIE设备唤醒,设置为允许

Windows 10 设置

  1. 控制面板–所有控制面板项–网络连接
  2. 在网卡适配器点击鼠标右键–属性,弹出的属性对话框中
  3. 选择网络选项卡–配置
  4. 选择高级选项卡,将关机 网络唤醒设置为开启,将魔术封包唤醒设置为开启
  5. 电源管理选项卡,勾选下面三个选项,允许此设备唤醒计算机。

ubuntu 20.04设置

$ sudo apt-get install ethtool

$ sudo apt-get install vim

$ sudo vim /etc/systemd/system/wol.service

里面的内容如下:

[Unit]
Description=Configure Wake On LAN

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -s eth0 wol g

# 如果有多张网卡
# ExecStart=/bin/bash -c '/sbin/ethtool -s enp5s0 wol g && /sbin/ethtool -s eth0 wol g'


[Install]
WantedBy=basic.target

上述配置是向驱动发送控制命令,启用网络唤醒功能。

启用服务

$ sudo systemctl daemon-reload

$ sudo systemctl enable wol.service

$ sudo systemctl start wol.service

远程唤醒

$ sudo apt-get install wakeonlan -y

$ wakeonlan MAC

也可尝试 etherwake

$ sudo apt-get install etherwake -y

$ etherwake MAC

# OpenWrt
# opkg install etherwake
# /usr/bin/etherwake -i br-lan MAC

参考链接


认识ARM64汇编

之前说过学习汇编就是学习寄存器和指令,查看代码请连接真机。

寄存器

arm64汇编中寄存器是64bit的,使用X[n]表示,低32位以w[n]表示

64位架构中有3164位的通用寄存器。

可以通过register read查看

(lldb) register read
General Purpose Registers:
        x0 = 0x0000000000000001
        x1 = 0x00000002805d8a20
        x2 = 0x00000002837e7980
        x3 = 0x00000002805d8a20
        x4 = 0x0000000000000001
        x5 = 0x0000000000000001
        x6 = 0x0000000100d54000  
        x7 = 0x0000000000000000
        x8 = 0x0000200000000000
        x9 = 0x000161a1d63f7945 (0x00000001d63f7945) (void *)0x01d63f7cb0000001
       x10 = 0x0000000000000000
       x11 = 0x000000000000006d
       x12 = 0x000000000000006d
       x13 = 0x0000000000000000
       x14 = 0x0000000000000000
       x15 = 0x00000001ca634e6d  "touchesBegan:withEvent:"
       x16 = 0x000000019c4cd47c  libobjc.A.dylib`objc_storeStrong
       x17 = 0x0000000000000000
       x18 = 0x0000000000000000
       x19 = 0x0000000100f17810
       x20 = 0x00000002837e7920
       x21 = 0x00000002805d8a20
       x22 = 0x00000001ca634e6d  "touchesBegan:withEvent:"
       x23 = 0x0000000100e11a30
       x24 = 0x00000002837e7980
       x25 = 0x0000000100e11a30
       x26 = 0x00000002805d8a20
       x27 = 0x00000001ca62d900  "countByEnumeratingWithState:objects:count:"
       x28 = 0x00000002805d8a20
        fp = 0x000000016f47d730
        lr = 0x00000001009866dc  ArmAssembly`-[ViewController touchesBegan:withEvent:] + 84 at ViewController.m:38
        sp = 0x000000016f47d720
        pc = 0x0000000100986720  ArmAssembly`foo1 + 16 at ViewController.m:46
      cpsr = 0x80000000
(lldb) 

继续阅读认识ARM64汇编

OpenSSL命令行校验SSL/TLS连接检查HTTPS证书配置是否正常

最近服务器上配置了`HTTPS`之后,发现证书无法通过验证,客户端报告异常

java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.

证书里面内容是正常的,并且通过浏览器是可以正常访问的,但是`Android APP`使用`okhttp`访问的时候就不能正常访问了。同样`IOS`应用访问也是异常的。

一脸懵逼,不清楚哪一步出现了问题。

于是想追踪一下正常的证书验证流程,搜索了一下发现如下命令:

# on a successful verification
# 注意需要指定端口,如果是https协议,默认端口也需要指定端口443
$ openssl s_client -quiet -connect jvt.me:443
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = jamietanna.co.uk
verify return:1

# on an unsuccessful verification
$ openssl s_client -quiet -connect keystore.openbanking.org.uk:443
depth=2 C = GB, O = OpenBanking, CN = OpenBanking Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=2 C = GB, O = OpenBanking, CN = OpenBanking Root CA
verify return:1
depth=1 C = GB, O = OpenBanking, CN = OpenBanking Issuing CA
verify return:1
depth=0 C = GB, O = OpenBanking, OU = Open Banking Directory, CN = keystore
verify return:1
read:errno=104

# for an expired cert
$ openssl s_client -quiet -connect expired.badssl.com:443
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL Wildcard, CN = *.badssl.com
verify error:num=10:certificate has expired
notAfter=Apr 12 23:59:59 2015 GMT
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL Wildcard, CN = *.badssl.com
notAfter=Apr 12 23:59:59 2015 GMT
verify return:1

目前校验过程中发现错误信息如下:

# 注意需要指定端口,如果是https协议,默认端口也需要指定端口443
$ openssl s_client -quiet -connect xxx.xxxxxx.com.cn:38080
depth=0 C = CN, ST = xxx, L = xxx, O = xxxx, OU = IT, CN = *.xxxxxx.com.cn
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = CN, ST = xxx, L = xxx, O = xxxx, OU = IT, CN = *.xxxxxx.com.cn
verify error:num=21:unable to verify the first certificate
verify return:1

经过相关的分析,发现这个问题的原因在于证书签发机构在签发证书的时候,下发了两个证书,其中一个是根证书,一个是中级证书,但是在配置的时候,没有配置相关的中级证书。导致证书校验异常。

增加中级证书之后,校验恢复正常。

参考链接


以太帧、ip帧、udp/tcp帧、http报文结构

从最简单的一个http请求开发,根据TCP/IP协议,分开来看每一层的数据帧结构,以及它们是怎样承担起网络服务的。

协议栈
因特网协议栈共有五层:

1.应用层,是网络应用程序及其应用层协议存留的地方。因特网的应用层包括许多协议,常见的有HTTP(它为web文档提供了请求和传送)、SMTP(它提供了电子邮件报文的传输)和FTP(它提供了两个端系统之间的文件传送)。

2.传输层,负责为信源和信宿提供应用程序进程(包括同一终端上的不同进程)间的数据传输服务,这一层上主要定义了两个传输协议,传输控制协议即TCP和用户数据报协议UDP。

3.网络层,负责将数据报独立地从信源发送到信宿,主要解决路由选择、拥塞控制和网络互联等问题。

4.链路层,负责将IP数据报封装成合适在物理网络上传输的帧格式并传输,或将从物理网络接收到的帧解封,取出IP数据报交给网络层。

5.物理层,负责将比特流在结点间传输,即负责物理传输。该层的协议既与链路有关也与传输介质有关。

继续阅读以太帧、ip帧、udp/tcp帧、http报文结构