SSL/TLS Programe In Linux
一、幾個名詞:
1. SSL(Secure Socket Layer)是Netscape公司設計的主要用於WEB的安全傳輸協議。這種協議在WEB上獲得了廣泛的應用。
2. IETF將SSL作了標準化，即RFC2246，並將其稱爲TLS（Transport Layer Security），從技術上講，TLS1.0與SSL3.0的差別非常微小。
SSL可以用於保密的傳輸，這樣我們與Web Server之間傳輸的消息便是“安全的”。
二、原理
1. SSL是一個介於HTTP協議與TCP之間的一個可選層，其位置大致如下：
|
－－－－－－－－－ | HTTP | －－－－－－－－－ | SSL | －－－－－－－－－ | TCP | －－－－－－－－－ | IP | －－－－－－－－－ |
SSL層：藉助下層協議的的信道安全的協商出一份加密密鑰，並用此密鑰來加密HTTP請求。
TCP層：與web server的443端口建立連接，傳遞SSL處理後的數據。接收端與此過程相反。
SSL在TCP之上建立了一個加密通道，通過這一層的數據經過了加密，因此達到保密的效果。
SSL協議分爲兩部分：Handshake Protocol和Record Protocol,。其中Handshake Protocol用來協商密鑰，協議的大部分內容就是通信雙方如何利用它來安全的協商出一份密鑰。 Record Protocol則定義了傳輸的格式。
2. 需要的加密方面的基礎知識
瞭解SSL原理需要一點點加密的概念，這裏把需要的概念做一下簡單闡述：
加密一般分爲三類，對稱加密，非對稱加密及單向散列函數。
對稱加密：又分分組密碼和序列密碼。
分組密碼是將明文按一定的位長分組，明文組經過加密運算得到密文組，密文組經過解密運算（加密運算的逆運算），還原成明文組。
序列密碼是指利用少量的密鑰（制亂元素）通過某種複雜的運算（密碼算法）產生大量的僞隨機位流，用於對明文位流的加密。
解密是指用同樣的密鑰和密碼算法及與加密相同的僞隨機位流，用以還原明文位流。
CBC(Cipher Block Chaining)模式這個詞在分組密碼中經常會用到，它是指一個明文分組在被加密之前要與前一個的密文分組進行異或運算。當加密算法用於此模式的時候除 密鑰外，還需協商一個初始化向量（IV），這個IV沒有實際意義，只是在第一次計算的時候需要用到而已。採用這種模式的話安全性會有所提高。
分組密碼的典型例子爲DES、RC5、IDEA。
序列密碼的典型例子爲RC4。
公鑰加密：
簡單的說就是加密密鑰與解密密鑰不同，分私鑰和公鑰。這種方法大多用於密鑰交換，RSA便是一個我們熟知的例子。
還有一個常用的稱作DH，它只能用於密鑰交換，不能用來加密。
單向散列函數：
由於信道本身的干擾和人爲的破壞，接受到的信息可能與原來發出的信息不同，一個通用的辦法就是加入校驗碼。
單向散列函數便可用於此用途，一個典型的例子是我們熟知的MD5,它產生128位的摘要，在現實中用的更多的是安全散列算法（SHA），SHA的早期版本存在問題，目前用的實際是SHA－1，它可以產生160位的摘要，因此比128位散列更能有效抵抗窮舉攻擊。
由於單向散列的算法都是公開的，所以其它人可以先改動原文，再生成另外一份摘要。解決這個問題的辦法可以通過HMAC（RFC 2104）,它包含了一個密鑰，只有擁有相同密鑰的人才能鑑別這個散列。
3. 密鑰協商過程
由於對稱加密的速度比較慢，所以它一般用於密鑰交換，雙方通過公鑰算法協商出一份密鑰，然後通過對稱加密來通信，當然，爲了保證數據的完整性，在加密前要先經過HMAC的處理。
SSL缺省只進行server端的認證，客戶端的認證是可選的。以下是其流程圖（摘自TLS協議）。
|
Client Server
Clienth*llo --------> Serverh*llo Certificate* ServerKeyExchange* CertificateRequest* <-------- Serverh*lloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data |
簡單的說便是：SSL客戶端（也是TCP的客戶端）在TCP鏈接建立之後，發出一個 Clienth*llo來發起握手，這個消息裏面包含了自己可實現的算法列表和其它一些需要的消息，SSL的服務器端會迴應一個Serverh*llo， 這裏面確定了這次通信所需要的算法，然後發過去自己的證書（裏面包含了身份和自己的公鑰）。Client在收到這個消息後會生成一個祕密消息，用SSL服 務器的公鑰加密後傳過去，SSL服務器端用自己的私鑰解密後，會話密鑰協商成功，雙方可以用同一份會話密鑰來通信了。
4. 加密的計算
上一步講了密鑰的協商，但是還沒有闡明是如何利用加密密鑰，加密初始化向量和hmac的密鑰來加密消息的。
其實其過程不過如此：
1 藉助hmac的密鑰，對明文的消息做安全的摘要處理，然後和明文放到一起。
2 藉助加密密鑰，加密初始化向量加密上面的消息。
三、安全性
SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的討論，目前也有一些成熟的工具如dsniff可以通過man in the middle攻擊來截獲https的消息。
從上面的原理可知，SSL的結構是嚴謹的，問題一般出現在實際不嚴謹的應用中。常見的攻擊就是middle inthe middle攻擊，它是指在A和B通信的同時，有第三方C處於信道的中間，可以完全聽到A與B通信的消息，並可攔截，替換和添加這些消息。
1 SSL可以允許多種密鑰交換算法，而有些算法，如DH，沒有證書的概念，這樣A便無法驗證B的公鑰和身份的真實性，從而C可以輕易的冒充，用自己的密鑰與雙方通信，從而竊聽到別人談話的內容。 而爲了防止middle inthe middle攻擊，應該採用有證書的密鑰交換算法。
2 有了證書以後，如果C用自己的證書替換掉原有的證書之後，A的瀏覽器會彈出一個警告框進行警告，但又有多少人會注意這個警告呢？
3 由於美國密碼出口的限制，IE，netscape等瀏覽器所支持的加密強度是很弱的，如果只採用瀏覽器自帶的加密功能的話，理論上存在被破解可能。
四、關於證書
如果對於一般的應用，管理員只需生成“證書請求”（後綴大多爲.csr），它包含你的名字和公鑰，然後把這份請求交給諸如verisign等有CA服務公司，你的證書請求經驗證後，CA用它的私鑰簽名，形成正式的證書發還給你。管理員再在web server上導入這個證書就行了。
從CA的角度講，你需要CA的私鑰和公鑰。從想要證書的服務器角度講，需要把服務器的證書請求交給CA。
如果你要自己做CA，別忘了客戶端需要導入CA的證書（CA的證書是自簽名的，導入它意味着你“信任”這個CA簽署的證書）。
而商業CA的一般不用，因爲它們已經內置在你的瀏覽器中了。
SSL/TLSv1.0 Programe
一、初始化
1. 加載所有的SSL算法和錯誤字符串信息:
加載SSL算法：
#define OpenSSL_add_ssl_algorithms() SSL_library_init()
#define SSLeay_add_ssl_algorithms() SSL_library_init()
所以load SSL算法的時候, 以上三個函數都是同樣的.
加載錯誤字符串信息：
SSL_load_error_strings();
bio_err=BIO_new_fp(stderr,BIO_NOCLOSE);
以後就可以調用ERR_print_errors(bio_err)打印出錯信息。
2. 建立SSL所用的method:
SSL_METHOD *meth=SSLv23_method(); // SSLv3 but can rollback to v2
另外還有兩個函數:
SSLv23_client_method(); //用於客戶端
SSLv23_server_method(); //用於服務端
v23表示使用的是SSL第三版本但是可以回滾到第二版本.還有一些其它的專門針對特定版本的建立method的方法:
SSL_METHOD *TLSv1_server_method(void); /* TLSv1.0 */
SSL_METHOD *TLSv1_client_method(void); /* TLSv1.0 */
SSL_METHOD *SSLv2_method(void); /* SSLv2 */
SSL_METHOD *SSLv2_server_method(void); /* SSLv2 */
SSL_METHOD *SSLv2_client_method(void); /* SSLv2 */
SSL_METHOD *SSLv3_method(void); /* SSLv3 */
SSL_METHOD *SSLv3_server_method(void); /* SSLv3 */
SSL_METHOD *SSLv3_client_method(void); /* SSLv3 */
3. 初始化上下文情景:
SSL_CTX *ctx=SSL_CTX_new(meth);
ctx->options|=SSL_OP_ALL
SSL/TLS有幾個公認的bug,這樣設置會使出錯的可能更小
SSL_CTX_set_options(ctx,SSL_OP_ALL);
4. 加載CA證書:
SSL_CTX_load_verify_locations(ctx, CAfile, CApath);
用於加載受信任的CA證書，用於驗證對方的證書.CAfile如果不爲NULL，則他指向的文件包含PEM編碼格式的一個或多個證書。
CApath如果不爲NULL，則它指向一個包含PEM格式的CA證書的目錄，目錄中每個文件包含一份CA證書，文件名是證書中CA名的HASH值.
5. 設置最大的驗證用戶證書的上級數。
SSL_CTX_set_verify_depth(ctx,10);
6. 設置臨時DH密鑰:
當使用RSA算法鑑別的時候，會有一個臨時的DH密鑰磋商發生。這樣會話數據將用這個臨時的密鑰加密，而證書中的密鑰中做爲簽名。 所以這樣增強了安全性，臨時密鑰是在會話結束消失的，所以就是獲取了全部信息也無法把通信內容給解密出來。
static unsigned char dh512_p[]={
0xDA,0x58,0x3C,0x16,0xD9,0x85,0x22,0x89,0xD0,0xE4,0xAF,0x75,
0x6F,0x4C,0xCA,0x92,0xDD,0x4B,0xE5,0x33,0xB8,0x04,0xFB,0x0F,
0xED,0x94,0xEF,0x9C,0x8A,0x44,0x03,0xED,0x57,0x46,0x50,0xD3,
0x69,0x99,0xDB,0x29,0xD7,0x76,0x27,0x6B,0xA2,0xD3,0xD4,0x12,
0xE2,0x18,0xF4,0xDD,0x1E,0x08,0x4C,0xF6,0xD8,0x00,0x3E,0x7C,
0x47,0x74,0xE8,0x33,
};
static unsigned char dh512_g[]={0x02,};
DH *dh=DH_new();
dh->p=BN_bin2bn(dh512_p,sizeof(dh512_p),NULL);
dh->g=BN_bin2bn(dh512_g,sizeof(dh512_g),NULL);
SSL_CTX_set_tmp_dh(ctx,dh);
7. 加載證書和私鑰:
私鑰可以和證書在一個文件之中。判斷私鑰和證書是否匹配。默認情況下,通信進行服務端證書的認證,所以客戶端可以不加載證書.
加載自己的證書：
char *cert_file="server.pem";
SSL_CTX_use_certificate_file(ctx, cert_file, SSL_FILETYPE_PEM);
由於私鑰有可能採用了密碼加密,所以獲取私鑰之前先寫上私鑰的密碼
char *pKeyPasswd="serve";
SSL_CTX_set_default_passwd_cb_userdata(ctx, pKeyPasswd);
加載自己的私鑰,以用於簽名：
SSL_CTX_use_PrivateKey_file(ctx, cert_file,SSL_FILETYPE_PEM);
檢查私鑰與密碼是否配對：
SSL_CTX_check_private_key(ctx);
設置一個臨時的RSA，在出口算法中，有規定需要這麼做的。
RSA *rsa=RSA_generate_key(512,RSA_F4,NULL,NULL);
SSL_CTX_set_tmp_rsa(ctx,rsa);
8. 設置驗證方式:
SSL_CTX_set_verify(ctx, mode, verify_callback*);
mode是以下值的邏輯或:
SSL_VERIFY_NONE表示不驗證;
SSL_VERIFY_PEER用於客戶端時要求服務器必須提供證書，用於服務器時服務器會發出證書請求消息要求客戶端提供證書，但是客戶端也可以不提供;
SSL_VERIGY_FAIL_IF_NO_PEER_CERT只適用於服務器且客戶端必須提供證書。他必須與SSL_VERIFY_PEER一起使用 .
任何一個驗證失敗信息都會終止TLS連接。但是是否證書就是不正確的呢，這要看視具體情況而定了，當SSL_VERIFY_PEER被設置時verify_callback可以控制驗證的行爲，比如自簽名錯誤或者證書過了有效期是否繼續，就可以通過這個回調函數來控制。
9. 產生session_id:
爲了從自己本身的程序中產生一個session_id，所以要給本程序設定一個session_id_context，否則程序從外部獲取session_id_context來得到session_id，那很容易產生錯誤 ,長度不能大於SSL_MAX_SSL_SESSION_ID_LENGTH
const unsigned char s_server_session_id_context[100]="1111asdfd";
SSL_CTX_set_session_id_context(ctx,s_server_session_id_context,
sizeof(s_server_session_id_context));
10. void RAND_seed(const void *buf,int num);
在win32的環境中client程序運行時出錯(SSL_connect返回-1)的一個主要機制便是與UNIX平臺下的隨機數生成機制不同(握手的時候用的到).解決辦法就是調用此函數,其中buf應該爲一隨機的字符串,作爲"seed".
至此初始化工作完成。下面是連接過程
二、連接過程
1. 客戶端：
普通的socket
sock = socket(AF_INET, SOCK_STREAM, 0);
addr.sin_family = AF_INET;
addr.sin_port = htons(port);
addr.sin_addr.s_addr = inet_addr(host);
connect(sock, (struct sock_addr *)&addr, sizeof (addr));
初始化SSL:
ssl = SSL_new(ctx);
與bio關聯：
sbio=BIO_new_socket(s,BIO_NOCLOSE);
SSL_set_bio(ssl,sbio,sbio);
SSL連接
SSL_connect(ssl);
獲得證書檢查的結果：
SSL_get_verify_result(ssl);
證書正常返回X509_V_OK, 其他錯誤號用命令man verify可以查看.
因爲SSL_get_verify_result函數，當沒有接收到證書的時候返回也是X509_V_OK,所以還需要使用函數SSL_get_peer_certificate(SSL* ssl)來確保接收到證書。
X509 *peer = SSL_get_peer_certificate(ssl);
2. 服務端：
普通的socket
sock = socket(AF_INET, SOCK_STREAM, 0);
addr.sin_addr.s_addr=INADDR_ANY;
addr.sin_family=AF_INET;
addr.sin_port=htons(HTTPS_PORT);
bind(sock, (struct sock_addr *)&addr, sizeof(addr) );
listen(sock, 5);
recv_sock = accept(sock, 0, 0);
初始化SSL：
ssl = SSL_new(ctx);
與bio關聯：
sbio=BIO_new_socket(s,BIO_NOCLOSE);
SSL_set_bio(ssl,sbio,sbio);
SSL accept:
SSL_accept(ssl);
獲得證書檢查的結果同客戶端。
至此整個的通信過程溝通完成，至於接收和發送數據很簡單，只要把正常的接收函數read和write函數替換成下面的兩個函數就可以了.
SSL_read(ssl, buf, size);
SSL_write(ssl, buf, size);
收尾工作：
當通信結束，需要做一些收尾工作，如下：
SSL_shutdown(ssl);
SSL_free(ssl);
SSL_CTX_free(ctx);
close(sock);
附：其他一些有用的函數
X509_NAME *X509_get_subject_name(X509 *a);
得到證書所有者的名字,參數可用通過SSL_get_peer_certificate()得到的X509對象.
X509_NAME *X509_get_issuer_name(X509 *a);
得到證書籤署者(往往是CA)的名字,參數可用通過SSL_get_peer_certificate()得到的X509對象.
X509_NAME_get_text_by_NID(X509_NAME *name, int nid, char *buf,int len);
根據name id得到各個name的信息。
char *X509_NAME_oneline(X509_NAME *a,char *buf,int size);
將以上三個函數得到的對象變成字符型,以便打印出來.