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;

还有个有意思的问题,如果一个https网站,用户访问的时候不小心输入了http的连接,一般服务器端会301 redirect,这样就产生了安全问题,称为https strip,具体不再赘述, 由这个问题引入了HSTS header,第一次访问(除外)之后都会在client浏览器端做306 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.android 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;

扩展: 流量加密 vpn