tls

DNS over TLS，让电信、移动等各种ISP无法监视你的浏览轨迹...... SSL证书有助于客户端浏览器和网站服务器之间的加密连接。 这意味着在连接期间，所有的通信和活动都被遮蔽。 但通常意义上的网站使用SSL证书依旧无法避免ISP监控你的浏览痕迹。而DNS over TLS正是为网络浏览自由而生。 什么是DNS over TLS? DNS over TLS是一项安全协议，它可以强制所有和DNS服务器相关的链接使用TLS。 TLS或传输层安全是SSL的后继。尽管我们常把SSL当成TLS的俗称，但其实SSL并不是什么安全协议，并迅速被TLS取代。而我们说的SSL证书，其实是TLS证书。因此当我们说TLS时，我们正在谈论SSL的概念。 什么是DNS服务器？ DNS指代域名服务器。DNS服务器的作用是将您输入的网址转换为计算机在网站服务时识别的IP地址。当你输入网站时，你输入的是URL或者统一资源定位器。而在后台，您的浏览器正在与DNS服务器建立连接，该服务器将该URL转换为IP地址，该IP地址用于服务于服务器上的文件。 这一切都在后台迅速发生。然而，大多数DNS请求都是以明文形式出现的，这意味着你的ISP可以看到信息交换。即便你浏览的这个网站使用了SSL，他们依旧可以看到你在干什么。 目前，请求是通过UDP或TCP协议进行的。 事实上，TLS over TLS在RFC

由于原本的服务器出故障，在使用临时服务器的时候出现苹果无法加载小程序 出现 request:fail 发生了 SSL 错误无法建立与该服务器的安全连接。 的问题 问题原因: 2017年1月1日起，苹果强制所有 app 满足 HTTPS，即 iOS9 推出的 App Transport Security (ATS) 特性。 输入域名，通过苹果ATS检测发现临时服务器并不支持TSL1.2，不满足ATS特性，所以需要配置服务器，打开TSL1.2 域名检测网址: http://s.tool.chinaz.com/ats/ 解决步骤: 1.运行regedit打开注册表 2.启用TLS1.2 进入[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols] 找到TL2 1.1 和TLS 1.2 将里面Server和Client两项的值均改为 DisabledByDefault [值 = 0] Enabled [值 = 1] 如果没有TLS1.1,TLS 1.2就新建 右键->新建->项->新建TLS 1.1,TLS 1.2 TLS 1.1和TLS 1.2 右键->新建->项->新建Server, Client 在新建的Server和Client中都新建如下的项(DWORD

##1 问题提出 现在广泛使用的HTTP协议采用的是一种明文传输的方式，因此通信双方的数据在网络上传输是十分不安全的。 ##2 解决方案 一种简单的解决方案就是对传输的数据进行加密处理。 目前流行的加密方式有两种：对称加密和非对称加密。 ###2.1 对称加密 首先讨论对称加密方式。 对称加密指的是通信双方使用同一套密钥对数据进行加密和解密。 如果使用对称加密就意味着通信的双方必须都知道密钥，才能完成加密和解密操作。 一种典型的场景是：客户端发送密钥至服务器，服务器接受该密钥，之后所有的数据传输都采用该密钥进行加密和解密； 该方法虽然可以解决明文传输的问题，却存在安全隐患。在密钥协商阶段，客户端需要发送密钥给服务器，此时如果攻击者监测到该密钥，就可以使用该密钥来解密之后所有的数据，那么本次经对称加密后的数据传输也就变为明文传输。 因此，如何确保对称加密方式中密钥的安全是此方式中最为核心的问题。 ###2.2 非对称加密 接下来我们讨论非对称加密方式。 非对称加密的密钥有公钥和私钥之分，使用公钥加密的数据只有私钥才能解密，同理使用私钥加密的数据只有公钥才能解密。 那么对传输数据进行非对称加密是不是就是安全的呢？ 非对称加密一种典型的场景是： 由服务器生成公钥和私钥，并将公钥发送给客户端，之后服务器和客户端之间所有的数据都采用公钥和私钥加密。 接下来我们分析下这种场景。

大多数人都厌烦使用老旧的系统，无论软件还是硬件。但有的时候又不得不困守其中，坚持延续着系统的寿命，或者还需要点几柱香，祈求神佛的护佑。 Linux是一个模块化极好的操作系统，得益于此，当其中有组件落伍之时，大多数情况下，还能通过下载源码，手工编译来升级组件，从而保证系统的可用性。 在这个过程中，cURL工具是必不可少的，特别很多常用的开发平台，都使用了libcurl库作为下载的基础工具。比如PHP/PYTHON/RUST/NPM等。当cURL出现故障的时候，直接就导致很多开发工具的升级或者安装依赖包无法继续。 今天碰到一个故障，一台有些年头的服务器在升级一个安全组件的时候报了一个错误： cURL error 35: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure 字面意思上看，是ssl3在握手的时候出现了错误。 但实际上，如果换用一台正常的设备访问同样的网站，再加上-v参数，能看到网站实际是用了TLS的加密方式： $ curl -v https://sh.rustup.rs * Rebuilt URL to: https://sh.rustup.rs/ * Trying 13.225.103.123... * TCP_NODELAY set * Connected to

0. 前置知识 非对称加密（比如RSA系列）算法运作机制： RSA(PrivateKey,MSG)=ENCODE,只能RSA(PublicKey，ENCODE)=MSG;RSA(PublicKey,MSG)=ENCODE,只能RSA(PrivateKey,ENCODE)=MSG RSA的难于破解基于这一数学事实: 对于两个大质数 p*q =n ,与N互质的数数量为(p-1)(q-1),当p或者q在1024位以上的时候要想寻找N的两个因子概率就太低了，而找到恰好的两个因子对（PublicKey,PrivateKey）就更难了。。。 1. 流程(报文及解释说明，以访问 https://www.baidu.com 为例子) 1.1. ClientHello（C2S） 字段 值 解释 Version TLS1.0 采用的TLS版本 Random 0acc.... 客户端生成的随机值client_random Cipher Suites TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 客户端支持的加解密算法组合列表，分为3个部分密钥交换算法(ECDHE_RSA)，批量加密算法(AES_128_GCM)，消息认证码算法(SHA256) TIP: Cipher Suite 分为3个部分： 密钥交换算法:决定客户端与服务器之间在握手时如何身份验证; 批量加密算法

一声惊雷，今天爆出了一个关于SSL协议的惊天大漏洞，在用完各种poc工具后，我们不妨来深入了解下这个高危漏洞的机理。 不管你是用网上公布的检测网站还是各个QQ群疯传的poc 脚本，知其然还要知其所以然，让我们知道漏洞形成的条件，以及漏洞产生的原理，如何修复这个惊天大漏洞。 这一次，腾讯的个别站点也没有幸免，果断是坑爹啊。点评ssl服务没有开启TLS heartbeat扩展，所以避过一劫，当然任何时候都不能说我们可以高枕无忧了，时刻得关注各种漏洞的发布与修复。 首先我们看一下某个有问题站点的SSL信息，当我们用openssl 以客户端模式连接对应网站的443端口的时候，会获取到对应服务器ssl协议中与TLS扩展相关的信息。 [root @king tests]# /usr/bin/openssl s_client -connect mail.xxx.com:443 -tlsextdebug 2>&1| grep 'TLS' TLS server extension "renegotiation info" (id=65281), len=1 TLS server extension "session ticket" (id=35), len=0 TLS server extension "heartbeat" (id=15), len=1 我们看到该站点开启了 heartbeat

1. pstree pstree以树结构显示进程 $ pstree -p work | grep ad sshd(22669)---bash(22670)---ad_preprocess( 4551 )-+ -{ad_preprocess}(4552) |-{ad_preprocess}(4553) |-{ad_preprocess}(4554) |-{ad_preprocess}(4555) |-{ad_preprocess}(4556) `-{ad_preprocess}(4557) work为工作用户，-p为显示进程识别码，ad_preprocess共启动了6个子线程，加上主线程共7个线程 2. ps -Lf $ ps -Lf 4551 UID PID PPID LWP C NLWP STIME TTY STAT TIME CMD work 4551 22670 4551 2 7 16:30 pts/2 Sl+ 0:02 ./ad_preprocess work 4551 22670 4552 0 7 16:30 pts/2 Sl+ 0:00 ./ad_preprocess work 4551 22670 4553 0 7 16:30 pts/2 Sl+ 0:00 ./ad_preprocess work 4551 22670 4554 0 7 16:30 pts/2 Sl+

iOS9 - NSAppTransportSecurity 配置要求 属性结构 属性详解 事例讲解 只有HTTPS 所有网址都不经过ATS关闭ATS 所有网址都经过ATS添加一些例外白名单 所有网址都不经过ATS添加例外 使用低等级版本的TLS协议 如何配置 iOS9 - NSAppTransportSecurity 原文地址: http://www.pluto-y.com/ios9-nsapptransportsecurity/ App Transport Security（以下均称 ATS ）是iOS9提供的一个新特性，主要是保证app和web服务之间的安全。如果不想开启的话，可以关闭这个特性。 所有用到 NSURLConnection 、 CFURL 以及 NSURLSession API都会触发 ATS (使用iOS9的SDK编译)验证, 所以在iOS9中需要符合一些配置才可以使 ATS 正常运行。 配置要求 关于App Transport Security 的一些进本配置要求： * 服务器只要支持TLS协议1.2 * 加密算法也是有限制，需要在以下列表中 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256

NSQ是目前比较流行的一个分布式的消息队列，本文主要介绍了NSQ及Go语言如何操作NSQ。 NSQ NSQ介绍 NSQ 是Go语言编写的一个开源的实时分布式内存消息队列，其性能十分优异。 NSQ的优势有以下优势： NSQ提倡分布式和分散的拓扑，没有单点故障，支持容错和高可用性，并提供可靠的消息交付保证 NSQ支持横向扩展，没有任何集中式代理。 NSQ易于配置和部署，并且内置了管理界面。 NSQ的应用场景 通常来说，消息队列都适用以下场景。 异步处理 参照下图利用消息队列把业务流程中的非关键流程异步化，从而显著降低业务请求的响应时间。 应用解耦 通过使用消息队列将不同的业务逻辑解耦，降低系统间的耦合，提高系统的健壮性。后续有其他业务要使用订单数据可直接订阅消息队列，提高系统的灵活性。 流量削峰 类似秒杀（大秒）等场景下，某一时间可能会产生大量的请求，使用消息队列能够为后端处理请求提供一定的缓冲区，保证后端服务的稳定性。 安装 官方下载页面 根据自己的平台下载并解压即可。 NSQ组件 nsqd nsqd是一个守护进程，它接收、排队并向客户端发送消息。 启动 nsqd ，指定 -broadcast-address=127.0.0.1 来配置广播地址 ./nsqd -broadcast-address=127.0.0.1 如果是在搭配 nsqlookupd 使用的模式下需要还指定

数字签名 用自己的私钥给数据加密就叫数字签名 公钥传输威胁 在A和B的通信中,C可以把自己的公钥发给A,让A把C的公钥当成B的公钥,这样的话.B拿到加密数据反而无法解密,而C却可以解密出数据.从而实现C截获AB之间的数据 所以在两者的通信中必须要对公钥的来源进行确认 A和B如果想安全交换公钥,就必须通过CA(证书颁发机构) 证书的通信过程 A和B首先都内置了CA的公钥 根CA的证书是自己给自己签名的(自签名) CA和证书 PKI: Public Key Infrastructure 签证机构：CA（Certificate Authority） 注册机构：RA 证书吊销列表：CRL 证书存取库： X.509：定义了证书的结构以及认证协议标准 版本号 序列号 签名算法 颁发者 有效期限 主体名称 主体公钥 CRL分发点 扩展信息 发行者签名 SSL SSL(Secure Socket Layer)和TLS(Transport Layer Security )本身是一个东西 实现功能: 机密性 认证 完整性 重放保护(正确同样的数据不能重复发送) 两阶段协议，分为握手阶段和应用阶段 握手阶段(协商阶段): 客户端和服务器端认证对方身份（依赖于PKI体系，利用数字证书进行 身份认证）,并协商通信中使用的安全参数、密码套件以及主密钥. 后续通信使用的所有密钥都是