近期有寻找Nginx的第三方模块库，其实Nginx第三次有官方公示：
https://www.nginx.com/resources/wiki/modules/
我的博客即将搬运同步至腾讯云+社区
我的博客即将搬运同步至腾讯云+社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=36vunkf53eg4o
为了“IPv6行动计划”落地，工信部推出21项举措
为贯彻落实《推进互联网协议第六版（IPv6）规模部署行动计划》，工业和信息化部将采取实施LTE网络端到端IPv6改造、加快固定网络基础设施IPv6改造、推进应用基础设施IPv6改造、开展政府网站IPv6改造与工业互联网IPv6应用、强化网络安全保障、落实配套保障措施等六方面二十一项举措。
工业和信息化部
关于贯彻落实《推进互联网协议第六版（IPv6）规模部署行动计划》的通知
工信部通信〔2018〕77号
各省、自治区、直辖市及计划单列市、新疆生产建设兵团工业和信息化主管部门，各省、自治区、直辖市通信管理局，部属各单位、部属各高校，中国电信集团有限公司、中国移动通信集团有限公司、中国联合网络通信集团有限公司，中国广播电视网络有限公司，阿里巴巴（中国）有限公司、深圳市腾讯计算机系统有限公司、百度在线网络技术（北京）有限公司、北京京东世纪信息技术有限公司、北京金山云网络技术有限公司、网宿科技股份有限公司、北京蓝汛通信技术有限责任公司、上海帝联信息科技发展有限公司、华为技术有限公司、广东欧珀移动通信有限公司、维沃移动通信有限公司、北京小米科技有限责任公司、魅族科技有限公司、上海优刻得信息科技有限公司、无锡华云数据技术服务有限公司、北京迅达云成科技有限公司、北京优帆科技有限公司、中山大学、东网科技有限公司、大连东软思维科技发展有限公司、宁夏誉成云创数据投资有限公司、蓝汛欣润科技（北京）有限公司、贵阳中电高新数据科技有限公司、贵阳综合保税区大数据科技有限公司、润泽科技 发展有限公司、武汉火凤凰云计算服务股份有限公司、湖南尚锐信息科技有限公司、启明信息技术股份有限公司、大连亿达名气通数据服务有限公司、沈阳铁路局、万国数据服务有限公司、成都中立数据科技有限公司、光环云谷科技有限公司、张北云联数据服务有限责任公司、上海数据港股份有限公司、阿里云计算有限公司（万网）、北京新网互联软件服务有限公司、中国互联网信息中心（CNNIC）、政府和公益机构域名注册管理中心（CONAC）、成都西维数码科技有限公司、厦门三五互联科技股份有限公司、厦门易名科技股份有限公司、江苏邦宁科技有限公司、浙江贰贰网络有限公司、佛山市亿动网络有限公司、厦门商中在线科技股份有限公司、广东时代互联科技有限公司：
为贯彻落实中共中央办公厅、国务院办公厅印发的《推进互联网协议第六版（IPv6）规模部署行动计划》（厅字〔2017〕47号，以下简称《行动计划》），加快网络基础设施和应用基础设施升级步伐，促进下一代互联网与经济社会各领域的融合创新，现就涉及我部相关任务的组织实施工作通知如下。
一、实施LTE网络端到端IPv6改造
（一）LTE网络IPv6改造。到2018年末，基础电信企业完成全国范围LTE核心网、接入网、承载网、业务运营支撑系统等IPv6改造并开启IPv6业务承载功能，为移动终端用户数据业务分配IPv6地址，提供端到端的IPv6访问通道。
（二）基础电信企业自营业务系统IPv6改造。到2018年末，基础电信企业完成门户网站、网上营业厅网站IPv6改造，并完成活跃用户规模排名前10位的自营移动互联网应用（APP）及相应系统服务器IPv6升级改造，使移动互联网应用（APP）支持IPv6访问优先；通过免流量升级等推广措施，引导用户完成移动互联网应用（APP）更新。
到2018年末，移动互联网IPv6用户规模不少于5000万户（基础电信企业已分配IPv6地址且一年内有IPv6上网记录的用户），其中，中国电信集团有限公司（简称中国电信）用户不少于1000万户，中国移动通信集团有限公司（简称中国移动）用户不少于3000万户，中国联合网络通信集团有限公司（简称中国联通）用户不少于1000万户。
（三）移动终端全面支持IPv6。推动新生产移动终端的出厂默认配置支持IPv4/IPv6双栈，并逐步推进存量移动终端通过系统软件升级开启IPv6功能。基础电信企业定制和集中采购的移动终端应全面支持IPv6。
（四）基础电信企业间网络与应用IPv6互通。到2019年第一季度末，各基础电信企业均完成LTE网络与其他基础电信企业用户规模排名前10位的移动互联网应用系统服务器互通，实现已选定的30个移动互联网应用（APP）IPv6跨网访问。
二、加快固定网络基础设施IPv6改造
（五）骨干网IPv6互联互通。到2018年末，完成北京、上海、广州、郑州、成都的互联网骨干直联点IPv6改造，开通IPv6网间互联带宽不少于1Tbps。到2020年末，完成所有互联网骨干直联点IPv6改造，开通IPv6网间互联带宽不少于5Tbps。
（六）城域网和接入网IPv6改造。到2018年末，基础电信企业完成城域网和接入网IPv6改造并开启IPv6业务承载功能，为固定宽带用户分配IPv6地址，向政企客户提供基于IPv6的专线业务，并出台相应的资费优惠措施。
（七）固定终端全面支持IPv6。推动新生产的家庭网关、企业网关、路由器等固定终端支持IPv6并默认配置支持IPv4/IPv6双栈，基础电信企业定制和集中采购的固定终端应全面支持IPv6。
（八）业务运营支撑系统改造。到2018年第三季度末，基础电信企业完成业务运营支撑系统升级改造，建立面向IPv6业务的运维管理体系和业务管理流程，具备IPv6用户统计、流量统计以及IPv6业务受理、开通、运行维护等能力。
三、推进应用基础设施IPv6改造
（九）数据中心IPv6改造。基础电信企业和数据中心运营企业应完成数据中心内部网络和出口设备的IPv6改造，支持IPv6业务接入和承载。到2018年末，中国电信、中国移动、中国联通完成超大型数据中心IPv6改造，国家超级计算广州中心、东北区域大数据中心、东软软件园数据中心、誉成云创数据中心、百度云计算技术（山西）有限公司、蓝汛首鸣国际数据中心完成IPv6改造，为用户提供基于IPv6的互联网数据中心（IDC）业务，2018年起新投产的数据中心应支持IPv6。到2020年末，各大型数据中心运营企业均完成IPv6改造。
（十）内容分发网络（CDN）IPv6改造。到2018年末，阿里云、腾讯云、金山云、网宿科技、蓝汛、帝联科技完成内容分发网络（CDN）IPv6改造。
（十一）云服务平台IPv6改造。到2018年末，中国电信、中国移动、中国联通面向公众提供服务的云服务平台完成50%云产品IPv6改造，阿里云、腾讯云、金山云、UCloud、华为云、华云、迅达云、百度云、京东云、青云等云服务平台企业完成50%云产品IPv6改造。到2020年末，上述企业完成全部云产品IPv6改造。鼓励云服务企业面向用户提供IPv6技术咨询、网站改造等服务。
（十二）域名系统IPv6改造。到2018年末，中国电信、中国移动、中国联通完成递归域名解析服务器的IPv6改造，万网、新网互联、中国互联网信息中心（CNNIC）、政府和公益机构域名注册管理中心（CONAC）、西部数码、三五互联、易名中国、中国数据、爱名网、联动天下、商务中国、时代互联完成IPv6改造，构建域名注册、解析、管理全链条IPv6支持能力。
四、开展政府网站IPv6改造
与工业互联网IPv6应用
（十三）政府网站IPv6改造。推进工业和信息化系统门户网站IPv6改造。到2018年末，工业和信息化部完成门户网站IPv6改造；到2019年末，部属各单位、部属各高校及各省、自治区、直辖市通信管理局完成门户网站IPv6改造。
（十四）工业互联网IPv6应用。鼓励典型行业、重点工业企业开展工业互联网IPv6网络化改造，创新工业互联网应用实践，构建工业互联网IPv6标准体系。
五、强化IPv6网络安全保障
（十五）加强IPv6网络安全管理。将IPv6相关网络基础设施及应用基础设施安全防护纳入电信和互联网网络安全防护体系，健全完善IPv6环境下网络安全相关管理和技术要求，开展针对IPv6的网络安全等级保护、风险评估、通报预警等工作。
（十六）做好IPv6网络安全保障措施升级改造。各基础电信企业和数据中心、内容分发网络（CDN）、云服务等运营企业要同步做好现有网络安全保障系统在IPv4向IPv6过渡过程中的升级改造，确保具备基于IPv6的安全保障能力。
（十七）强化IPv6网络安全能力建设。加强基于IPv6固定网络基础设施和应用基础设施的网络安全防护手段建设，支持开展IPv6网络环境下的工业互联网、物联网、人工智能等新兴领域网络安全技术和管理机制研究。鼓励企业、研究机构、高校等各方加强协同，加快IPv6安全技术研发、应用和融合创新。
六、落实配套保障措施
（十八）加强组织领导。各地通信管理局、工业和信息化主管部门要加强与有关部门的沟通协调，建立协同工作机制。各基础电信企业集团公司、设备制造企业以及数据中心、内容分发网络（CDN）、云服务、域名服务等企业要成立由公司领导任组长的专项推进工作组，对照各项目标任务制定具体实施方案和工作计划，并于5月15日前报送工业和信息化部（信息通信发展司）。
（十九）落实主体责任。各企业要加大资金投入力度，确保各项目标任务按期完成。各基础电信企业集团公司在对各省级子（分）公司的业绩考核中，还应将IPv6相关任务完成情况作为重要的考核指标，要安排资金保障IPv6各项任务落实。各企业应于2018年6月、9月、12月底向工业和信息化部（信息通信发展司）报送相关工作进展情况。
（二十）强化规范管理。完善互联网信息服务备案管理制度，鼓励互联网接入服务提供者和互联网信息服务提供者提供基于IPv6的服务，在互联网信息服务备案时明确要求提供IPv6相关信息；加强IPv6地址备案系统的建设和备案管理，督导企业严格落实IPv6接入地址编码规划方案；完善相关电信业务管理要求，要求数据中心（含云服务）、内容分发网络（CDN）等运营企业在提交年报时，提供支持IPv6相关情况；修订电信设备进网检测的相关规定，明确网络及终端设备进网中有关IPv6的检测要求。各地工业和信息化主管部门在电子政务系统、信息化系统及服务平台等项目审批中，应将支持IPv6作为必要条件，并负责考核落实；要统筹安排专项资金，加大对本地区IPv6改造工作的支持力度。
（二十一）加强督查考核。工业和信息化部将成立IPv6督查工作专家组，研究制定推进IPv6规模部署相关任务完成情况的考核标准，并将定期组织开展专项督查工作，就LTE网络IPv6端到端贯通、固定网络基础设施改造、应用基础设施改造、强化网络安全保障等重点任务进行分项考核。中国信息通信研究院要研究构建IPv6发展监测平台，形成对网络、应用、终端、用户、流量等关键发展指标的实时监测和分析能力，并向社会发布IPv6各项发展指标数据。
工业和信息化部
2018年4月25日
看来IPV6实施已经开始，大家拭目以待吧。
SSL/TLS加密检测脚本testssl.sh
以前SSL检测常用工具就是ssllabs的：https://www.ssllabs.com/ssltest/ 以及国内的https://myssl.com/.
检测方法很简单，输入在线检测即可。
今天在网上有发现一款好用的SSL检测脚本：testssl.sh：https://testssl.sh/
检测方法就是下载源码，运行：
git clone --depth 1 https://github.com/drwetter/testssl.sh.git
然后进入目录：
运行：帮助shuom
testssl.sh --help
运行检测：
./testssl.sh yourdomain.com
检测结果类型如下：
###########################################################
testssl.sh 3.0beta from https://testssl.sh/dev/
(470f8b6 2018-04-28 22:38:53 -- )
This program is free software. Distribution and
modification under GPLv2 permitted.
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
Please file bugs @ https://testssl.sh/bugs/
###########################################################
Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers]
on VM_122_230_centos:./bin/openssl.Linux.x86_64
(built: "Jun 22 19:32:29 2016", platform: "linux-x86_64")
Start 2018-04-29 23:25:20 -->> 119.28.6.33:443 (zach.xin) <<--
rDNS (119.28.6.33): --
Service detected: HTTP
Testing protocols via sockets except NPN+ALPN
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 offered
TLS 1.1 offered
TLS 1.2 offered (OK)
TLS 1.3 not offered
NPN/SPDY h2, http/1.1 (advertised)
ALPN/HTTP2 h2, http/1.1 (offered)
Testing cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication) not offered (OK)
Export ciphers (w/o ADH+NULL) not offered (OK)
LOW: 64 Bit + DES encryption (w/o export) not offered (OK)
Weak 128 Bit ciphers (SEED, IDEA, RC[2,4]) not offered (OK)
Triple DES Ciphers (Medium) not offered (OK)
High encryption (AES+Camellia, no AEAD) offered (OK)
Strong encryption (AEAD ciphers) offered (OK)
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
PFS is offered (OK) ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA
Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519
Testing server preferences
Has server cipher order? yes (OK)
Negotiated protocol TLSv1.2
Negotiated cipher ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Cipher order
TLSv1: ECDHE-RSA-AES128-SHA AES128-SHA ECDHE-RSA-AES256-SHA AES256-SHA
TLSv1.1: ECDHE-RSA-AES128-SHA AES128-SHA ECDHE-RSA-AES256-SHA AES256-SHA
TLSv1.2: ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA AES128-GCM-SHA256 AES128-CCM8 AES128-CCM AES128-SHA256 AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA AES256-GCM-SHA384 AES256-CCM8 AES256-CCM AES256-SHA256 AES256-SHA
Testing server defaults (Server Hello)
TLS extensions (standard) "renegotiation info/#65281" "EC point formats/#11" "session ticket/#35" "status request/#5" "next protocol/#13172" "max fragment length/#1"
"application layer protocol negotiation/#16" "encrypt-then-mac/#22" "extended master secret/#23"
Session Ticket RFC 5077 hint 600 seconds, session tickets keys seems to be rotated < daily
SSL Session ID support yes
Session Resumption Tickets: yes, ID: yes
TLS clock skew Random values, no fingerprinting possible
Signature Algorithm SHA256 with RSA
Server key size RSA 2048 bits
Server key usage Digital Signature, Key Encipherment
Server extended key usage TLS Web Server Authentication, TLS Web Client Authentication
Serial / Fingerprints 049CA937F746C261709C994D3484D78B958A / SHA1 C654AA97C778B10F79B05E12F679146255984AC8
SHA256 F1137B78E829E1AEC2F238F931835A0090DBCF01C6F57B48F5CF16C2295B0EB4
Common Name (CN) zach.xin
subjectAltName (SAN) www.zach.xin zach.xin
Issuer Let's Encrypt Authority X3 (Let's Encrypt from US)
Trust (hostname) Ok via SAN and CN (same w/o SNI)
Chain of trust Ok
EV cert (experimental) no
Certificate Validity (UTC) 78 >= 30 days (2018-04-18 19:06 --> 2018-07-17 19:06)
# of certificates provided 2
Certificate Revocation List --
OCSP URI http://ocsp.int-x3.letsencrypt.org
OCSP stapling offered
OCSP must staple extension --
DNS CAA RR (experimental) not offered
Certificate Transparency yes (certificate extension)
Testing HTTP header response @ "/"
HTTP Status Code 403 Forbidden
HTTP clock skew 0 sec from localtime
Strict Transport Security not offered
Public Key Pinning --
Server banner nginx
Application banner --
Cookie(s) (none issued at "/") -- maybe better try target URL of 30x
Security headers --
Reverse Proxy banner --
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK)
ROBOT not vulnerable (OK)
Secure Renegotiation (CVE-2009-3555) not vulnerable (OK)
Secure Client-Initiated Renegotiation not vulnerable (OK)
CRIME, TLS (CVE-2012-4929) not vulnerable (OK)
BREACH (CVE-2013-3587) no HTTP compression (OK) - only supplied "/" tested
POODLE, SSL (CVE-2014-3566) not vulnerable (OK)
TLS_FALLBACK_SCSV (RFC 7507) Downgrade attack prevention supported (OK)
SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK)
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
make sure you don't use this certificate elsewhere with SSLv2 enabled services
https://censys.io/ipv4?q=F1137B78E829E1AEC2F238F931835A0090DBCF01C6F57B48F5CF16C2295B0EB4 could help you to find out
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected
BEAST (CVE-2011-3389) TLS1: ECDHE-RSA-AES128-SHA AES128-SHA ECDHE-RSA-AES256-SHA AES256-SHA
VULNERABLE -- but also supports higher protocols TLSv1.1 TLSv1.2 (likely mitigated)
LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches
RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK)
Testing 364 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (RFC)
-----------------------------------------------------------------------------------------------------------------------------
xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
xc028 ECDHE-RSA-AES256-SHA384 ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
x9d AES256-GCM-SHA384 RSA AESGCM 256 TLS_RSA_WITH_AES_256_GCM_SHA384
xc0a1 AES256-CCM8 RSA AESCCM8 256 TLS_RSA_WITH_AES_256_CCM_8
xc09d AES256-CCM RSA AESCCM 256 TLS_RSA_WITH_AES_256_CCM
x3d AES256-SHA256 RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA256
x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA
xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
xc027 ECDHE-RSA-AES128-SHA256 ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
xc013 ECDHE-RSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
xc0a0 AES128-CCM8 RSA AESCCM8 128 TLS_RSA_WITH_AES_128_CCM_8
xc09c AES128-CCM RSA AESCCM 128 TLS_RSA_WITH_AES_128_CCM
x9c AES128-GCM-SHA256 RSA AESGCM 128 TLS_RSA_WITH_AES_128_GCM_SHA256
x3c AES128-SHA256 RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA256
x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA
Running client simulations via sockets
Android 4.2.2 TLSv1.0 ECDHE-RSA-AES128-SHA, 256 bit ECDH (P-256)
Android 4.4.2 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Android 5.0.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Android 6.0 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Android 7.0 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 253 bit ECDH (X25519)
Chrome 57 Win 7 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 253 bit ECDH (X25519)
Chrome 65 Win 7 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 253 bit ECDH (X25519)
Firefox 53 Win 7 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 253 bit ECDH (X25519)
Firefox 59 Win 7 TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 253 bit ECDH (X25519)
IE 6 XP No connection
IE 7 Vista TLSv1.0 ECDHE-RSA-AES128-SHA, 256 bit ECDH (P-256)
IE 8 Win 7 TLSv1.0 ECDHE-RSA-AES128-SHA, 256 bit ECDH (P-256)
IE 8 XP No connection
IE 11 Win 7 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
IE 11 Win 8.1 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
IE 11 Win Phone 8.1 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
IE 11 Win 10 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Edge 13 Win 10 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Edge 13 Win Phone 10 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Edge 15 Win 10 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 253 bit ECDH (X25519)
Opera 17 Win 7 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
Safari 9 iOS 9 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Safari 9 OS X 10.11 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Safari 10 OS X 10.12 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Apple ATS 9 iOS 9 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Tor 17.0.9 Win 7 TLSv1.0 ECDHE-RSA-AES128-SHA, 256 bit ECDH (P-256)
Java 6u45 TLSv1.0 AES128-SHA
Java 7u25 TLSv1.0 ECDHE-RSA-AES128-SHA, 256 bit ECDH (P-256)
Java 8u161 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Java 9.0.4 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
OpenSSL 1.0.1l TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
OpenSSL 1.0.2e TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Done 2018-04-29 23:27:55 [ 158s] -->> 119.28.6.33:443 (zach.xin) <<--
博客名字
昨天处理CDN的时候，突然想到为啥我的博客要叫这个名字？
本质上这就是一个我的个人博客，原来名字就叫Zach’s Blog，后来转到国内换成了一个VIP域名。
转国内云服务商自然免不了要备案了，于是我在填写备案信息的时候看到了我无意中选的顶部图，一副落日的景象，遂填写了一个日暮星辰。纯属偶得。
也罢，难得人生诗酒花，醉与落日然绯霞。
DNS解析迁移回国内
最近中美贸易关系闹得挺乱，突然发现在国际政治面前，一切遮羞布都是渣渣。
为了规避中中美国际政治风险，把源CloudFlare的域名解析全部迁移回国内。
本来想换位百度DNS智能云解析 ，后来发现它只能解析已备案域名，所以没备案的就没戏了。
另外百度的DNS域名解析识别备案也出错，一个.XIN域名总是识别为没备案。于是我只放了一个域名在上面，买了个9快钱的普惠版凑合用着。百度解析没有什么特殊的功能。
在闲逛的时候无意发现一家新的云安全服务商，有免费的域名解析服务：上海云盾信息技术有限公司（YUNDUN） ，主要业务为云安全服务。旗下业务有安全的DNS云解析，本来以为平淡无奇，进去发现还是不错，有完善的分区解析，比DNSPOD那小气劲可算是大方多了。看其VIP服务差异不大。还是希望它能够办下去，毕竟国内靠谱的域名解析服务不多了。
回过头来想想，中兴这次事件也为我们的基础服务敲响了警钟，虽然网络无国界，自由平等开源其实很多时候还是受到政治制约的。
从这些云解析中看来，还是希望国内的云服务商都争气，完善好我们自己的网络和服务吧。截止目前，我一直在使用着阿里云、腾讯云、京东云，国外的VPS也很少用了。
使用Oneinstack实现TLS1.3部署
一直在使用OneInstack，一直为网站部署了SSL，随着TLS1.3的草案落实发布，Openssl也发布了多个草案适配的TLS1.3的OPENSSL测试版套件。本文在此提供一种方案实现部署TLS1.3实现draft 23.
1.按照OneInstack网站下载WEB运维脚本源码，解压。
2.修改根目录下versions.txt文件，修改Openssl和NGINX版本要求，目前是为了下载适用的openssl-1.1.1-pre2版本和NGINX版本
nginx_ver=1.13.11
openssl_ver=1.1.1-pre2
3.修改oneinstack源码中./include/check_download.sh文件中openssl-1.1.1-pre2下载连接，由于新版本的openssl-1.1.1-pre3和pre4版本的发布，openssl官网上的pre2的连接更新至：https://www.openssl.org/source/old/1.1.1/openssl-1.1.1-pre2.tar.gz
echo "Download openSSL..."
src_url=https://www.openssl.org/source/old/1.1.1/openssl-${openssl_ver}.tar.gz && Download_src
4.按照以上设置，按照正常的oneinstack安装程序安装会出现x25519-x86_64一个文件的编译错误，是由于在openssl-1.1.1-pre2源码中一直存在一个错误：在./crypto/ec/asm/x25519-x86_64.pl 文件中末尾存在一个变量错误，更正如下：
close STDOUT;
考虑下载的覆盖问题，我建议直接下载openssl-1.1.1-pre2源码修改完成打包文件名为openssl-1.1.1-pre2.tar.gz直接放置于oneinstack源码中./src文件夹中。安装时候才不会下载源码覆盖。
5.完成以上后可以正常安装编译。完成后新建vhost网站，修改nginx对应的conf设置：
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
修改完成重启nginx
6.设置浏览器支持tls1.3
目前最新版 Chrome 和 Firefox 都支持 TLS 1.3，但需要手动开启：
- Chrome，将
chrome://flags/中的Maximum TLS version enabled改为TLS 1.3（Chrome 62 中需要将TLS 1.3改为Enabled (Draft)）； - Firefox，将
about:config中的security.tls.version.max改为4；
目前ssllabs和myssl两个ssl检测网站都无法识别tls1.3 draft 23，因此检测不到TLS1.3.
至此，网站已经正常启用TLS1.3
Cloudflare 1.1.1.1公共DNS上线Cloudflare Public DNS
什么是公共DNS
我们都知道，我们要能上网，就必须要使用DNS。这个DNS可能是你的运营商提供给你的，也可以是一些其它组织提供的，比如我们熟知的谷歌的8.8.8.8，国内114dns的114.114.114.114. 。他们负责给我们的请求提供解析服务。
不过首先要明白，公共DNS不是：
- 不是根服务器
- 不是权威dns托管商，不提供域名注册等服务，比如万网和DNSpod
- 不是权威dns，不针对个别域名进行解析
公共DNS服务的特点就是服务的域名数量巨大，用户数多，同时要求具有安全性和抗攻击性，低延迟（响应快），无拦截（无广告）以及对解析成功率要求非常的高。
近期，深耕于域名解析DNS和CDN的国外知名服务商Cloudflare上线了其下的免费公共DNS服务，其与 APNIC合作推出了免费的公共DNS解析服务：
DNS解析服务IP为：
IPV4：1.1.1.1 1.0.0.1
IPV6：2001:2001:: 2001:2001:2001::
从IP都直接看来，颇具诚意。
以前国外特色的DNS公共DNS解析服务有：
GOOGLE IPV4：8.8.8.8 8.8.4.4
Quad 9 (IBM)：9.9.9.9
Let’s Encrypt 宣布 ACME v2 正式支持通配符证书
Let’s Encrypt 宣布 ACME v2 正式支持通配符证书。
证书周期仍然为3个月，通配符证书需要acme.sh dnsapi模式.
以前的certbot验证方式只是从单域名的DNS模式。
Let’s Encrypt 宣布 ACME v2 正式支持通配符证书。Let’s Encrypt 宣称将继续清除 Web 上采用 HTTPS 的障碍，让每个网站轻松获取管理证书。
v2 vs v1
ACME v2 与 v1 API 有许多不同之处，值得注意的变更：
- 授权/签发流程已改变
- JWS 请求授权以改变
- JWS 请求体的”resource”字段被新的 JWS 请求头“url”替换
- 目录端点/资源重命名
ACMEv 是 ACME 协议的更新版本，考虑到行业专家和其他组织可能希望在某天使用 ACME 协议进行证书颁发和管理，它已经通过 IETF 标准流程。
通配符证书 允许使用单个证书来保护域的所有子域。在某些情况下，通配符证书可以使证书更容易管理，以帮助使 Web 达到 100％ 的 HTTPS 协议。但是对于大多数用例，Let’s Encrypt 仍然推荐使用非通配符证书。
通配符证书只能通过 ACMEv2 获得。为了将 ACMEv2 用于通配符或非通配符证书，你需要一个已更新且支持 ACMEv 的客户端。Let’s Encrypt 希望所有客户和订户转换为 ACMEv2，尽管 ACMEv1 API 还没有“报废”。
另外，通配符域必须使用 DNS-01 质询类型进行验证。这表明你需要修改 DNS TXT 记录才能演示对域的控制以获得通配符证书。
更多有关 ACME v2 和通配符证书的技术信息，请参阅此文章：
- https://community.letsencrypt.org/t/acme-v2-production-envrionment-wildcards/55578
通配符证书解释：
域名通配符证书类似 DNS 解析的泛域名概念，主域名签发的通配符证书可以在所有子域名中使用。
通配符证书的优势：
域名通配符证书最大的特点就是申请之后可以部署在子域名使用， 因此对于子域名，没有必要再次申请新的证书。
而价格方面，通配符域名证书通常会比单域名证书高几倍， 不过价格高的主要原因自然是使用的便利性。
.xyz域名解析管理的坑
.xyz一直是国内比较心水的域名，作为字母域名，一直从小唱着字母歌，做着XYZ的方程式长大的中国民众来说，很多人很喜欢这个后缀域名。
在早之前注册了一个.xyz域名，每次更改解析服务商或者更改域名解析记录，总会出现注册局的根域更新很慢。
都21世纪了，还要等个好久。前天更改了域名解析服务商，三天过去了，今天查询还是找不到A记录。我也是醉了。
随便搜索了一下，.xyz的注册局确认有时候抽风不靠谱。详见：https://www.v2ex.com/t/246719
只能说各自珍重吧。
PS,用的国外的解析无法传递到国外根域，换成CloudFlare竟然好了。
See U!