本站源服务器将在2020-08-06 03:00:00 PM UTC进行安全维护操作,预计离线时长为1小时

在AnyConnect中使用可信SSL证书(Let's Encrypt)
Hibiki Diary

在AnyConnect中使用可信SSL证书(Let's Encrypt)

前言 作者地址:https://zorz.cc/post/anyconnect-with-trusted-ssl.html 在本博客以前的文章中介绍过anyconnect开源服务端ocserv的安装,但是之前为了方便,介绍的是自签SSL证书,自签证书在自用的情况当然没啥问题(如果你看到警告不开心,也可以申请可信的SSL证书),但如果是分享给别人使用,客户端连接服务端时出现的警告可能会导致一些误会,这里介绍一下如何在anyconnect中使用可信的ssl证书。 准备 需要准备的东西: 一台服务器 一个域名 将二级域名的A记录指向你的服务器(如A.yourdomain.com),当然你也可以直接用主域名指向你的服务器。 可以使用免费的域名:freenom.com 一个SSL证书:如果只有一个服务端可以使用https://freessl.org/申请亚洲诚信的证书,该证书具有一年有效期,不必频繁的续期,如果有数个服务端,申请证书可以会比较麻烦,就可以通过脚本申请Let's Encrypt的泛域证书,申请教程,这里以cloudflare为例:申请泛域证书,然后可以通过脚本自动续期,并通过scp,https,Resilio sync等方式分发到anyconnect服务端节点,这样可以简单方便的实现在多个服务端节点使anyconnect具有可信SSL证书。 本文是ubuntu16.04环境下的ocserv的安装与使用,同样适用于debian 安装ocserv并配置 大部分内容还是参考以前的文章 检查PPP/TUN环境 cat /dev/net/tun # 返回的必须是: cat: /dev/net/tun: File descriptor in bad state 安装依赖 sudo apt-get update sudo apt-get install pkg-config build-essential libgnutls28-dev libwrap0-dev liblz4-dev libseccomp-dev libreadline-dev libnl-nf-3-dev libev-dev gnutls-bin -y 编译安装 然后我们新建一个文件夹,并下载和编译安装 ocserv,此处用的 ocserv 可能不是最新的,最新的请看:ocserv mkdir ocserv && cd ocserv wget ftp://ftp.infradead.org/pub/ocserv/ocserv-0.12.2.tar.xz tar -xJf ocserv-0.12.2.tar.xz && cd ocserv-0.12.2 ./configure make make install # 安装后的文件可以不删除,卸载的时候还需要用到。 最后我们新建一个配置文件的文件夹: mkdir /etc/ocserv wget -N --no-check-certificate -P "/etc/ocserv" "https://files.zorz.cc/ocserv.conf" 上面下载的是doub.io大佬根据 ocserv 默认配置文件稍微改了改以适应教程的配置文件。 如果你想要自己改配置文件可以去看源码默认自带的配置文件: ocserv-0.12.2/doc/sample.config 配置参数解释 auth = "plain[passwd=/etc/ocserv/ocpasswd]" # 这个是登陆方式,plain[passwd=/etc/ocserv/ocpasswd] 代表使用密码登陆并且从 /etc/ocserv/ocpasswd 文件中读取用户名和密码 # listen-host = [IP|HOSTNAME] # 这个代表监听的IP或主机名,注释掉即可。 tcp-port = 443 udp-port = 443 # 这个代表 TCP和UDP监听的端口 默认443,如果端口被干扰或被占用,可以更换其他端口,端口号可分开 server-cert =…

黑暗之后,便是曙光

GPG入门指南(加密/签名)
Hibiki Diary

GPG入门指南(加密/签名)

我们平时都听过非对称加密,公钥和私钥,签名验证,但这些证书都是怎么得到的呢?本篇文章会解答这些问题。 背景介绍 加密的一个简单但又实用的任务就是发送加密电子邮件。多年来,为电子邮件进行加密的标准一直是PGP(Pretty Good Privacy)。程序员Phil Zimmermann特别为电子邮件的保密编写的PGP。 这个软件非常好用,迅速流传开来,成了许多程序员的必备工具。但是,它是商业软件,不能自由使用。 作为PGP的替代,如今已经有一个开放源代码的类似产品可供使用。GPG(Gnu Privacy Guard),它不包含专利算法,能够无限制的用于商业应用。 本文将会介绍文件加密,至于GPG的其他用途,比如邮件加密,请参考这个网站https://help.ubuntu.com 安装 本人使用mac电脑,因此使用brew安装的,很简单,打开终端,输入brew install gpg就行了,至于其他的平台,可以自行搜索。   bogon:~ XXXX$ brew install gpg ==> Downloading https://homebrew.bintray.com/bottles/gnupg-1.4.20.el_capitan.bot ######################################################################## 100.0% ==> Pouring gnupg-1.4.20.el_capitan.bottle.tar.gz 🍺 /usr/local/Cellar/gnupg/1.4.20: 53 files, 5.4M 安装完成后,键入命令gpg --help:   bogon:~ XXXX$ gpg --help gpg (GnuPG) 1.4.20 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg 支持的算法: 公钥:RSA, RSA-E, RSA-S, ELG-E, DSA 对称加密:IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 散列:MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 压缩:不压缩, ZIP,…

果然上网课就很难集中精神呢……Image result for 天使降临到我身边 表情包

GoDaddy竟然不给.pro域名上Cloudflare指定的DNSSEC Algorithm 13算法 :leng:

本站启用HTTP/3 QUIC支持
Hibiki Diary

本站启用HTTP/3 QUIC支持

前年的这个时候,国内网络环境开始普及和部署 HTTP/2. 时隔一年,HTTP/2 的普及程度有了显著提升,而各大CDN厂商普及的广度和速度一直走在行业前列。甚至有不少CDN厂商在直播以及部分HTTP场景还引入了 QUIC. 在拙文《当我们在谈论HTTP队头阻塞时,我们在谈论什么?》中,我们提到,HTTP/2 over QUIC 是当前唯一应用落地解决了传输层队头阻塞问题的HTTP实现。那个时候,无论是 HTTP/2 over TCP 还是 HTTP/2 over QUIC(UDP) 都被我们认为是 HTTP/2,只是传输层使用的协议不一样。这种略带暧昧的模糊叫法在2018年11月成为了历史: 在2018年10月28日的邮件列表讨论中,互联网工程任务组(IETF) HTTP和QUIC工作组主席Mark Nottingham提出了将HTTP-over-QUIC更名为HTTP/3的正式请求,以“明确地将其标识为HTTP语义的另一个绑定……使人们理解它与QUIC的不同”,并在最终确定并发布草案后,将QUIC工作组继承到HTTP工作组。在随后的几天讨论中,Mark Nottingham的提议得到了IETF成员的接受,他们在2018年11月给出了官方批准,认可HTTP-over-QUIC成为HTTP/3。 虽然看起来像是之前的 HTTP/2 over QUIC 换了一个名称(从我个人角度理解,取名为 HTTP/2.1也许更合适),但是其背后却体现了 IETF 对 HTTP 未来标准的态度和方向,也许几年以后来看这次名称的确立会更加明白其重要意义。 HTTP/3 与 HTTP/2 over QUIC 的区别 QUIC 将成为一个通用安全传输层协议 当前阶段,Google 实现的 QUIC 与 IETF 实现的 QUIC 是不兼容的。Google 版 QUIC 只能用于 HTTP/2,且在协议层面与 HTTP/2 有一些强绑定。如 QUIC 帧映射 HTTP/2 frame. 这就导致很多大厂都没有跟进 QUIC,使得 HTTP/2 over QUIC 基本只能在 Google 自家的 Chrome, Gmail 等软件中普及使用,一度给行业造成“只有Google在弄”的错觉。 纳入 IETF 以后,显然 Google 就不能这么玩了。QUIC 定位为一个通用安全传输层协议。 可以近似的认为 QUIC over UDP 将成为下一代(或替代)TLS over TCP. 也就是说, QUIC 将能应用于任何应用层协议中,只是当前阶段将优先在 HTTP 中进行应用和验证。 统一使用 TLS 1.3 作为安全协议 2018年,有几个重要的WEB标准终于尘埃落定,其中一个便是 RFC 8446 TLS 1.3. 这个标准对于降低延迟,改善用户体验,尤其是移动端的体验有非常重要的意义。在拙文《TLS1.3/QUIC 是怎样做到 0-RTT 的》中,我们提到 虽然 TLS 1.3和 QUIC 都能做到 0-RTT,从而降低延迟,但是 QUIC 却自顾自地实现了一套安全协议。主要是因为当时 TLS 1.3 标准还没有发布,而…

网站页面大幅度改版 ✧(•̀ω•́ )
Hibiki Diary

网站页面大幅度改版 ✧(•̀ω•́ )

从原来的Bulk Blog主题更改为魔改后的kratos-pjax 更改以后简直焕然一新,变得更二次元了(bushi 以后的日子里会经常更新Blog,会记录一些Hibiki的日常,或者技术相关IT相关ACG相关和谐相关……(咳咳   (突然有种想向某神社的网站定位看齐的冲动     kratos-pjax项目Github: https://github.com/xb2016/Kratos-pjax