SSL&TLS Tips
- 2019 年 12 月 30 日
- 筆記
每天的日常編碼工作：就是解決一個問題的時候再創造另外一個問題 Orz…..
話說剛才生成一個私鑰的時候， Python3綁定libssl1.1 又崩了；正在痛苦思考中~~~
現在有兩個選擇:
- 放棄ssl動態庫調用，反正我只用ECDSA，所以找個原生庫來用好啦
- 死磕openssl，把它徹底搞明白
利弊權衡之下我選擇了1，不過當然我也在2上花了一點時間，複習了一下基礎知識，在此記錄下來。
libssl3是個什麼東東
在探究libssl.so的時候，我無意發現我的系統裏面還有一個libssl3.so；這個是什麼東東？我印象裏面openssl還只有1.x版本才對；
我在ubuntu16.04下查看這個so文件來源;
|
1 2 |
~ locate libssl3.so /usr/lib/x86_64-linux-gnu/libssl3.so |
|---|
nm看一下:
|
1 2 3 |
~ nm /usr/lib/x86_64-linux-gnu/libssl3.so nm: /usr/lib/x86_64-linux-gnu/libssl3.so: no symbols |
|---|
奇怪，沒有任何符號；繼續用ldd看一下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
~ ldd /usr/lib/x86_64-linux-gnu/libssl3.so ldd /usr/lib/x86_64-linux-gnu/libssl3.so linux-vdso.so.1 => (0x00007ffe833bb000) libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x00007faf3cc8a000) libnssutil3.so => /usr/lib/x86_64-linux-gnu/libnssutil3.so (0x00007faf3ca5d000) libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so (0x00007faf3c858000) libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so (0x00007faf3c619000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007faf3c3fc000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faf3c032000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007faf3be18000) libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so (0x00007faf3bc14000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007faf3ba10000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007faf3b808000) /lib64/ld-linux-x86-64.so.2 (0x00007faf3d21d000) |
|---|
嗯，找到了一個有意思的依賴:libnss3.so
再用命令dpkg看一下
|
1 2 |
~ dpkg -S /usr/lib/x86_64-linux-gnu/libnss3.so libnss3:amd64: /usr/lib/x86_64-linux-gnu/libnss3.so |
|---|
基本上確定是libnss3這個庫引入的libssl3.so了，最後再用dpkg確認一下:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
~ dpkg-query -L libnss3 /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libnssutil3.so /usr/lib/x86_64-linux-gnu/nss /usr/lib/x86_64-linux-gnu/nss/libfreebl3.chk /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so /usr/lib/x86_64-linux-gnu/nss/libsoftokn3.so /usr/lib/x86_64-linux-gnu/nss/libsoftokn3.chk /usr/lib/x86_64-linux-gnu/nss/libfreeblpriv3.chk /usr/lib/x86_64-linux-gnu/nss/libfreeblpriv3.so /usr/lib/x86_64-linux-gnu/nss/libnssdbm3.chk /usr/lib/x86_64-linux-gnu/nss/libnssdbm3.so /usr/lib/x86_64-linux-gnu/nss/libfreebl3.so /usr/lib/x86_64-linux-gnu/nss/libnsssysinit.so /usr/lib/x86_64-linux-gnu/libsmime3.so /usr/lib/x86_64-linux-gnu/libnss3.so /usr/lib/x86_64-linux-gnu/libssl3.so /usr/share /usr/share/doc /usr/share/doc/libnss3 /usr/share/doc/libnss3/copyright /usr/share/doc/libnss3/changelog.Debian.gz /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/libnss3 |
|---|
libnss3是個什麼東東?
|
1 |
apt-cache show libnss3 |
|---|
看了一下，發現是mozilla基金會搞得東東；再google一下，發現是自己孤陋寡聞了；
原來，SSL&TSL的實現，不只是openssl一家獨大，像Mozilla Firefox就用自家實現的Nss；
Google Chrome之前也是用Nss的，後來遷移到了openssl，再後來，2014年，openssl1.0.1出現了heartbeat 漏洞，Google乾脆自己開了個分支，用自己定製的openssl了；
至於Windows平台的，還有C++陣營的，都有自己實現的ssl庫，具體可參見:
https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/de-ruiter
nss在centos中
搜素的過程中，我驚奇的發現，ubuntu和centos上面的curl，竟然鏈接的libssl也不一樣：
ubuntu上的curl默認鏈接的是openssl，而centos上面默認鏈接的是libnss3；
耐人尋味啊，莫非redhat系的人發現了什麼~~~~
做事要做全套，我分別切換到ubuntu16.04和centos7.2上面，看看他們官方倉庫中自帶的curl是如何編譯的。
centos7.2
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
~ rpm -q –requires curl libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.17)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_2.7)(64bit) libcurl = 7.29.0-51.el7 libcurl.so.4()(64bit) libdl.so.2()(64bit) libnspr4.so()(64bit) libnss3.so()(64bit) libnssutil3.so()(64bit) libplc4.so()(64bit) libplds4.so()(64bit) libpthread.so.0()(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) libsmime3.so()(64bit) libssl3.so()(64bit) libz.so.1()(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) rpmlib(PayloadIsXz) <= 5.2-1 |
|---|
用的是libcurl = 7.29.0-51.el7；
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
~ rpm -q –requires libcurl /sbin/ldconfig libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.15)(64bit) libc.so.6(GLIBC_2.16)(64bit) libc.so.6(GLIBC_2.17)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_2.7)(64bit) libcom_err.so.2()(64bit) libdl.so.2()(64bit) libgssapi_krb5.so.2()(64bit) libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit) libidn.so.11()(64bit) libidn.so.11(LIBIDN_1.0)(64bit) libk5crypto.so.3()(64bit) libkrb5.so.3()(64bit) liblber-2.4.so.2()(64bit) libldap-2.4.so.2()(64bit) libnspr4.so()(64bit) libnss3.so()(64bit) libnss3.so(NSS_3.10)(64bit) libnss3.so(NSS_3.12.1)(64bit) libnss3.so(NSS_3.12.5)(64bit) libnss3.so(NSS_3.2)(64bit) …. |
|---|
看到libnss3了,重點輸出：
|
1 |
libnss3.so |
|---|
那麼這個包是誰提供的？輸入如下命令：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
~ rpm -qf /usr/lib64/libnss3.so nss-3.36.0-7.1.el7_6.x86_64 ~ rpm -ql nss /etc/pki/nss-legacy /etc/pki/nss-legacy/nss-rhel7.config /etc/pki/nssdb /etc/pki/nssdb/cert8.db /etc/pki/nssdb/cert9.db /etc/pki/nssdb/key3.db /etc/pki/nssdb/key4.db /etc/pki/nssdb/pkcs11.txt /etc/pki/nssdb/secmod.db /usr/lib64/libnss3.so /usr/lib64/libnssckbi.so /usr/lib64/libsmime3.so /usr/lib64/libssl3.so /usr/lib64/nss/libnssckbi.so … |
|---|
至此水落石出，還可以看到我們熟悉的證書cert8.db文件；但其實 curl 最終使用的根證書庫並不是該文件。那 curl 使用的根證書文件在哪兒呢？
使用 curl-config 命令行工具，能夠了解更多：
|
1 2 |
~ curl-config –ca /etc/pki/tls/certs/ca-bundle.crt |
|---|
ubuntu16.04
ubuntu16上面驗證類似，不一一說明了~~~
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
~ dpkg-query -L libcurl3 /. /usr /usr/share /usr/share/doc /usr/share/doc/libcurl3 /usr/share/doc/libcurl3/copyright /usr/share/doc/libcurl3/changelog.Debian.gz /usr/share/doc/libcurl3/NEWS.Debian.gz /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/libcurl3 /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0 /usr/lib/x86_64-linux-gnu/libcurl.so.3 /usr/lib/x86_64-linux-gnu/libcurl.so.4 |
|---|
|
1 2 3 4 5 6 7 8 9 |
~ apt-cache depends libcurl3 Depends: libc6 Depends: libgssapi-krb5-2 Depends: libidn11 Depends: libldap-2.4-2 Depends: librtmp1 Depends: libssl1.0.0 Depends: zlib1g Recommends: ca-certificates |
|---|
然後尋找libcurl的依賴庫:
|
1 2 |
~ ldd /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0|grep ssl libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007fbdf8aa0000) |
|---|
驗證一下:
|
1 2 3 4 5 6 7 8 |
~ apt-cache depends openssl openssl Depends: libc6 Depends: libssl1.0.0 Suggests: ca-certificates ~ apt-cache rdepends libssl1.0.0 | grep curl libcurl3 |
|---|
總結
所以這就是想要解決一個問題的中途，又被帶到了另外一條小路上；該說我是還有那麼一點好奇心呢？還是注意力不集中呢？
Orz………
參考資料:
https://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/de-ruiter
https://zh.wikipedia.org/wiki/%E5%BF%83%E8%84%8F%E5%87%BA%E8%A1%80%E6%BC%8F%E6%B4%9E
https://www.lbbniu.com/6680.html
