1、幾個名詞:web
1. SSL(Secure Socket Layer)是Netscape公司設計的主要用於WEB的安全傳輸協議。這種協議在WEB上得到了普遍的應用。算法
2. IETF將SSL做了標準化,即RFC2246,並將其稱爲TLS(Transport Layer Security),從技術上講,TLS1.0與SSL3.0的差異很是微小。瀏覽器
SSL能夠用於保密的傳輸,這樣咱們與Web Server之間傳輸的消息即是「安全的」。安全
2、原理服務器
1. SSL是一個介於HTTP協議與TCP之間的一個可選層,其位置大體以下:session
---------socket | 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 藉助加密密鑰,加密初始化向量加密上面的消息。
3、安全性
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能夠輕易的冒充,用本身的密鑰與雙方通訊,從而竊聽到別人談話的內容。 而爲了防止middlein the middle攻擊,應該採用有證書的密鑰交換算法。
2 有了證書之後,若是C用本身的證書替換掉原有的證書以後,A的瀏覽器會彈出一個警告框進行警告,但又有多少人會注意這個警告呢?
3 因爲美國密碼出口的限制,IE,netscape等瀏覽器所支持的加密強度是很弱的,若是隻採用瀏覽器自帶的加密功能的話,理論上存在被破解可能。
4、關於證書
若是對於通常的應用,管理員只需生成「證書請求」(後綴大多爲.csr),它包含你的名字和公鑰,而後把這份請求交給諸如verisign等有CA服務公司,你的證書請求經驗證後,CA用它的私鑰簽名,造成正式的證書發還給你。管理員再在web server上導入這個證書就好了。
從CA的角度講,你須要CA的私鑰和公鑰。從想要證書的服務器角度講,須要把服務器的證書請求交給CA。
若是你要本身作CA,別忘了客戶端須要導入CA的證書(CA的證書是自簽名的,導入它意味着你「信任」這個CA簽署的證書)。
而商業CA的通常不用,由於它們已經內置在你的瀏覽器中了。
SSL/TLSv1.0 Programe
1、初始化
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".
至此初始化工做完成。下面是鏈接過程
2、鏈接過程
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);
將以上三個函數獲得的對象變成字符型,以便打印出來.