who are you talking to ?

client和server如何互相确认

两个问题，client怎么知道自己是跟目标server通信，比如gmail服务器而不是黑客服务器； server怎么知道是这个用户在跟自己通信而不是

1.ssh ssh连接server，第一次连接时会有fingerprint提示信息，一般我们都忽略这个提示，yes记住fingerprint， 如果第一次就是黑客劫持的对话那就没办法了，第一次之后就可以放心，因为client已经记住了server的fingerprint，不会被黑客欺骗；

server怎么记住client呢，我们将client端自签名的证书扔到server上，一般是.ssh目录

2.web app http明文不安全； https通信是http建立在tls上，最新的tls1.3，client会validate server：通过验证CA证书， 如果黑客获取了合法的CA或者通过手段将自己的自签名证书安装到用户电脑，就可以进行中间人攻击；

我们进行流量抓取和监听采用的方法就是自签名证书，挂代理的方式； 同理一般公司都会自签证书，安装到每台机器上，这样就可以监控每台电脑的流量；

这些是正常的监控，但是怎么避免被黑客采用了类似手段进行监控呢，跟ssh中fingerprint类似思想，引入key pinning:

• public key pinning recommend, never change
• certificate pinning not recommend, may expire
• subject public key info pinning

  example in https://en.wikipedia.org/wiki/X.509
  Subject Public Key Info:
          Public Key Algorithm: id-ecPublicKey
              Public-Key: (256 bit)
          pub: 
                  00:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5:
                  af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e:
                  9d:3b:ef
              ASN1 OID: prime256v1
              NIST CURVE: P-256
  			
  

  HPKP is a Trust on First Use (TOFU) technique. The first time a web server tells a client via a special HTTP header which public keys belong to it, the client stores this information for a given period of time. When the client visits the server again, it expects at least one certificate in the certificate chain to contain a public key whose fingerprint is already known via HPKP. If the server delivers an unknown public key, the client should present a warning to the user. https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning

第一次访问会返回response header携带public key或者subject public key info，一般都是一年才过期，client浏览器会记住对应的domain和public key信息， 这样第一次（除外）之后，如果发生黑客劫持，黑客只要无法提供已经记录的public key信息（当然是需要签名的），或者说无法提供certificate chain上面的任何一个public key信息， 则浏览器会拒绝或者warning； 坏处是万一管理员配错了一次key，浏览器会记住一年，除了手动去清理（普通用户无法做到），没有办法revoke，这就有个问题： Problem: hostile pinning If the unthinkable — server compromise! — happens, the attacker could set a new pin set for their own server. The attacker could: ● Lock clients into the attacker’s server ● Deny service to the site, long-term In many cases, though, server compromise enables so many extreme losses that hostile pinning pales in comparison. 解决方案是这个http based key pinning header被Deprecated

还有个有意思的问题，如果一个https网站，用户访问的时候不小心输入了http的连接，一般服务器端会301 redirect，这样就产生了安全问题，称为https strip，具体不再赘述， 由这个问题引入了HSTS header，第一次访问（除外）之后都会在client浏览器端做307 internal redirect，直接将http加上s；

Most users don’t specify the protocol in URLs typed into the address bar, so if you request www.netsparker.com (or just netsparker.com), the browser will assume the default HTTP protocol and send an HTTP request to http://www.netsparker.com. Because the Netsparker site uses HSTS to enforce HTTPS-only communication, it responds with a redirect to the HTTPS site (301 response code) and includes the Strict-Transport-Security response header to indicate that only the HTTPS version of the site will be served. NTP Attacks on HSTS For the present, HSTS is a fairly robust way of enforcing HTTPS connections. The only practical approach to compromising HSTS is based on attacks against the Network Time Protocol (NTP) that attempt to manipulate system time by faking time values from NTP servers. This allows attackers to fool the browser into expiring HSTS entries and allowing insecure HTTP connections. Note that this is not a problem intrinsic to HSTS – NTP vulnerabilities can also be used for attacks against other security technologies and protocols, including SSL/TLS, Kerberos and Active Directory. https://www.netsparker.com/blog/web-security/http-strict-transport-security-hsts/

hsts还引入了“super” cookie的问题，注意跟https://en.wikipedia.org/wiki/HTTP_cookie#Supercookie 这个不一样，

Why "super"? First, it's much harder to get rid of compared to regular cookie: most of modern browsers provide user with no interface to manage HSTS storage. Second, in some browsers (mostly in Chromium-based) HSTS cookie will remain even when site is accessed in "private mode". Third, Safari iOS and OS X, when connected to iCloud, share and sync HSTS storage across devices, so being marked on one machine user becomes trackable on all his devices. See below for details. http://hsts.nevkontakte.com/ 先讲解下通常的cookie，我们从浏览器的cookie删除就删除了， 下一次访问，server会给一个新的cookie，通常的广告tracking也基本都是，比如访问 a.com，嵌入的三方广告商ad.com会设置一个cookie（因为网站主主动嵌入，所以广告商会给网站主一个id），只要用户不手动清除，之后用户访问b.com刚好同样嵌入了ad.com广告， 此时ad.com就可以读取之前设置的cookie，如果有值，ad.com后台就可以通过cookie值和分配给这些网站主的id来确认这个用户访问过比如很多编程相关的网站，所以就可以定制推送编程广告；

hsts “super” cookie工作原理

a website might contain multiple single-pixel beacons, each requested over HTTP from a different subdomain controlled by the attacker. By specifying or omitting HSTS headers in specific replies, the attacker can store a potentially unique pattern in the browser’s HSTS database, in effect assigning a fingerprint. When the browser visits the site again, it will attempt to use HTTPS to load the beacons that initially had the HSTS header in replies, and plain HTTP for the remaining ones. By reading this pattern, the attacker can identify and track the returning browser. No cookies are used, and fingerprinting works across multiple sessions and regardless of incognito mode, so these identifiers have been dubbed “supercookies”. https://www.netsparker.com/blog/web-security/http-strict-transport-security-hsts/ 意思是一个恶意网站可以abuse hsts，比如用户第一次访问evil.com，evil.com会做几件事情： 1）生成一个8位unique id给用户，比如0000 0001，0代表http，1代表https， 2）根据这个id对应返回给用户一个html页面包含8个资源：

	0bit.evil.com/test.css
	1bit.evil.com/test.css
	....
	7bit.evil.com/test.css
	
0bit对应0000 0001的1，其他对应这些0，访问0bit.evil.com/test.css则header返回Strict-Transport-Security: "max-age=31536000", forcing all further requests to that subdomain to be sent over HTTPS；
访问1bit.evil.com/test.css等则是Strict-Transport-Security: "max-age=0", allowing further requests to that subdomain to be sent over plain HTTP.

即使我们不写入任何cookie给这个用户，等到下一次用户再来访问evil.com，我们仍然知道这个用户是0000 0001，how？ 很容易，evil.com通过请求这个8个资源是http(0)还是https(1)就可以重组0000 0001，从而定位用户； https://security.stackexchange.com/questions/79518/what-are-hsts-super-cookies/79522

然后想办法将evil.com嵌入到其他网站，比如通过论坛群聊窗口等，当然了也可以通过分析evil.com的来源refer url来给用户画像；

上面都是说client通常是浏览器怎么确保server身份，那么server怎么确认client的身份呢，从https或者tls的角度，server不care！ 因为这是通信协议，不care很正常，但是应用层通常是需要根据业务需求对用户进行authenticate然后才能authorize， authenticate则通常是通过cookie和session的方式进行维护用户对话状态，这就引入了csrf，xssi，xss等攻击方式

3.desktop software and app

app和server之间可以通过https通信也可以通过其他协议通信，大致的攻防策略跟上面类似；

不同的是：

app我们开发之后是安装在用户端的，所以很自然的我们可以将前面说的key pinning公钥信息直接写死到app安装包里面， app packaged and shipped with baked in public key, so it can verify the information from server;

然后对于ios app，需要开发者签名，并且提交到apple，申请让apple签名，类似于CA的工作原理，这样才可以跟外界通信；

然后对于桌面软件也是类似，分几种情况说明：

1）桌面软件表现为跟浏览器类似的行为，走http通过internet去跟外界部署的比如某个web server通信，这样是默认允许的，一般操作系统默认80开启；

2）但是如果反过来incoming connection，比如桌面软件自己开启了一个http server是比较危险的，具体参照我之前讲到的zoom漏洞案例分析，比如在本机监听某个端口（当然肯定是非80端口）， 如果不指定127.0.0.1，则默认绑定所有网卡（有时候是只绑定ipv6），这样局域网内任意机器都可以访问，当然默认防火墙会屏蔽掉外部连接过来的流量When bound to all interfaces, incoming connections are usually still blocked by the operating system firewall； 如果需要从外部连接一般需要加防火墙设置，可以手动或者当你安装软件的时候，软件会自动设置（一般会问同意或者弹出admin权限请求“Windows firewall has blocked some features of this app”，一般没人去看）； 如果是mac电脑，跟ios app一样，还需要申请apple的签名才能加入防火墙白名单！； 经过这些设置，外界（软件的服务器端）就可以跟安装在用户电脑的应用发起通信了，当然软件内部肯定也要一份白名单来限制不要任意ip都能连过来！

而我说软件在本地开启http server比较危险是因为，不管你设置没设置防火墙，黑客都无所谓，因为黑客可以这样做： 当用户访问黑客站点时，站点上内嵌的指向localhost http server的请求，因为这是相当于本机内部请求，如果软件没写好，请求是会被执行的，具体的攻防涉及到same origin/preflight request/dns rebinding等， 参考zoom案例分析，所以没事不要搞一个可以从普通浏览器就唤醒的http server（用户无察觉），可以搞一个其他协议的server，比如注册一个zoom://，浏览器不会直接执行而是去提醒用户唤醒软件，这样用户就会察觉！

4.IOT设备

跟前面都不同的是，很多IOT设备运行的操作系统都是极简化的，基本都没有防火墙，意味着可以直接从internet连上去！

扩展： 流量加密 vpn