Web API應用支持HTTPS的經驗總結

在我前面介紹的WebAPI文章里面,介紹了WebAPI的架構設計方面的內容,其中提出了現在流行的WebAPI優先的路線,這種也是我們開發多應用(APP、微信、微網站、商城、以及Winform等方面的整合)的時候值得考慮的線路之一。一般情況下,由于HTTP協議的安全性,傳遞的參數容易被攔截,從而可能導致潛在的危險,所以一般WebAPI接口層都采用了HTTPS協議的,也就是采用SSL層來對數據進行安全性的加密的。

1、HTTPS基礎知識介紹

1) HTTPS
HTTPS(全稱:Hypertext Transfer Protocol over Secure Socket Layer),是以安全為目標的HTTP通道,簡單講是HTTP的安全版。即HTTP下加入SSL層,HTTPS的安全基礎是SSL,因此加密的詳細內容就需要SSL。 它是一個URI scheme(抽象標識符體系),句法類同http:體系。用于安全的HTTP數據傳輸。https:URL表明它使用了HTTPS,但HTTPS存在不同于HTTP的默認端口及一個加密/身份驗證層(在HTTP與TCP之間)。這個系統的最初研發由網景公司進行,提供了身份驗證與加密通訊方法,現在它被廣泛用于萬維網上安全敏感的通訊,例如交易支付方面。
2)HTTPS和HTTP的區別
  一、https協議需要到ca申請證書,一般免費證書很少,需要交費。
  二、http是超文本傳輸協議,信息是明文傳輸,https 則是具有安全性的ssl加密傳輸協議。
  三、http和https使用的是完全不同的連接方式,用的端口也不一樣,前者是80,后者是443。
四、http的連接很簡單,是無狀態的;HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議,比http協議安全。
3)https的實現原理
有兩種基本的加解密算法類型
1)對稱加密:密鑰只有一個,加密解密為同一個密碼,且加解密速度快,典型的對稱加密算法有DES、AES等;
2)非對稱加密:密鑰成對出現(且根據公鑰無法推知私鑰,根據私鑰也無法推知公鑰),加密解密使用不同密鑰(公鑰加密需要私鑰解密,私鑰加密需要公鑰解密),相對對稱加密速度較慢,典型的非對稱加密算法有RSA、DSA等。

https的通信過程


4) https通信的優點
1)客戶端產生的密鑰只有客戶端和服務器端能得到;
2)加密的數據只有客戶端和服務器端才能得到明文;
3)客戶端到服務端的通信是安全的。

2、SSL基礎知識介紹

1)SSL安全套接層協議(Secure Socket Layer)
  為Netscape所研發,用以保障在Internet上數據傳輸之安全,利用數據加密(Encryption)技術,可確保數據在網絡上之傳輸過程中不會被截取及竊聽。目前一般通用之規格為40 bit之安全標準,美國則已推出128 bit之更高安全標準,但限制出境。只要3.0版本以上之IE或Netscape瀏覽器即可支持SSL。
  當前版本為3.0。它已被廣泛地用于Web瀏覽器與服務器之間的身份認證和加密數據傳輸。
SSL協議位于TCP/IP協議與各種應用層協議之間,是一種國際標準的加密及身份認證通信協議,為TCP提供一個可靠的端到端的安全服務,為兩個通訊個體之間提供保密性和完整性(身份鑒別)。SSL協議可分為兩層:SSL記錄協議(SSL Record Protocol):它建立在可靠的傳輸協議(如TCP)之上,為高層協議提供數據封裝、壓縮、加密等基本功能的支持。SSL握手協議(SSL Handshake Protocol):它建立在SSL記錄協議之上,用于在實際的數據傳輸開始前,通訊雙方進行身份認證、協商加密算法、交換加密密鑰等。
2)SSL協議特點
1)SSL協議可用于保護正常運行于TCP之上的任何應用協議,如HTTP、FTP、SMTP或Telnet的通信,最常見的是用SSL來保護HTTP的通信。
2)SSL協議的優點在于它是與應用層協議無關的。高層的應用協議(如HTTP、FTP、Telnet等)能透明地建立于SSL協議之上。
3)SSL協議在應用層協議之前就已經完成加密算法、通信密鑰的協商以及服務器的認證工作。在此之后應用層協議所傳送的數據都會被加密,從而保證通信的安全性。
4)SSL協議使用通信雙方的客戶證書以及CA根證書,允許客戶/服務器應用以一種不能被偷聽的方式通信,在通信雙方間建立起了一條安全的、可信任的通信通道。
5)該協議使用密鑰對傳送數據加密,許多網站都是通過這種協議從客戶端接收信用卡編號等保密信息。常用于交易過程中。

3)SSL功能
1)客戶對服務器的身份認證:
SSL服務器允許客戶的瀏覽器使用標準的公鑰加密技術和一些可靠的認證中心(CA)的證書,來確認服務器的合法性。

2)服務器對客戶的身份認證:
也可通過公鑰技術和證書進行認證,也可通過用戶名,password來認證。

3)建立服務器與客戶之間安全的數據通道:
SSL要求客戶與服務器之間的所有發送的數據都被發送端加密、接收端解密,同時還檢查數據的完整性。


3、支持SSL的CA證書購買

上面介紹一些基礎知識,我們可以簡單的概括一下,就是引入了HTTPS,可以很好解決接口參數的安全性問題。這些在很多大廠商的接口里面,都是使用HTTPS協議的,如騰訊微信、支付寶等接口,特別對于支付內容,使用HTTPS是必須的。
對于支持HTTPS,核心的問題就是解決證書的問題,必須是由第三方權威機構頒發的證書,這樣才能達到不被偽造的可能性,一般我們采用的是CA證書,這些證書是需要通過付費購買的(天下沒有免費的午餐),證書的購買的供應商網站有很多,可以選擇自己合適的進行購買。
1)國外的GoDaddy平臺購買證書過程
這個參考博客園站長dudu的介紹內容,這個goDaddy是支持支付寶用美元購買的,使用平臺是英文,可以購買域名、證書等服務,是一個影響力較大的廠商。
1) 打開godaddy.com網站,通過菜單進入Products -> SSL&Security -> SSL Certificates,選擇Protect All Subdomains("Wildcard"), 在Pick your plan type中,選擇Standard(Validates domain ownership),然后完成購買。
2)進入My Account -> SSL CERTIFICATES,創建證書(Certificate),創建時將之前得到的CSR內容復制到“CSR文本框”中。
3)接入來進入GoDaddy的審批流程,在審批過程中需要驗證域名的所有者(dns填加記錄或上傳html文件至網站目錄),驗證成功后很快就會生成CA證書。
4)下載CA證書文件至生成CSR的服務器上。

普通證書費用是63美元左右,可以通過支付寶進行交易。


2)國內沃通平臺購買證書過程
這個是純中文版本的平臺,比較方便使用,費用也比上面的貴一些,分的級別好像也多一些,相對上面那個國外的GoDaddy的三個種類證書,這個產品線分了6個類型。最低的也要接近500塊,相對GoDaddy來說,費用要多一些了。由于是初步使用,也就購買了這個使用了。
申請購買也很簡單,一步步按提示操作填寫內容即可,大致分為這幾步:
1)輸入購買的證書類型,以及年限等資料;
2)輸入域名的信息,以及需要域名對應的郵件進行驗證;
3)提交購買訂單后,使用在線支付或者使用公司賬號匯款到指定賬號;
4)客服驗證后,技術人員提供證書生成操作,我們在列表里面盡快使用證書密碼下載證書。

最后成功后,在訂單信息里面,有這樣的列表,提供了兩個SHA1和SHA2兩種加密協議的證書,官方建議使用SHA2。


4、Web API應用支持HTTPS

有了證書,我們在云服務器上(如阿里云)的IIS里面的證書模塊里面,可以導入已有的證書。


導入證書成功后,我們可以看到列表里面有具體的證書了,同時雙擊可以查看證書詳細信息。


創建一個網站,并指定使用這個證書,端口采用443即可。

一般情況下,我們創建這個步驟后,你可以使用類似這樣地址:(https://www.iqidi.com)。
測試下具體的網站是否已經開通了,如果可以正常訪問,那說明你的443端口已經啟動偵聽了,如果沒有,可能是沒有啟動,或者是防火墻禁止了,一般情況下,我們還是需要在防火墻里面增加443端口的入站規則,設置為允許,否則可能被屏蔽了。

如果都設置了,可以通過DOS命令行來檢查端口是否已經開始偵聽了。
查詢443端口監聽
netstat -ano | find "443"

如果還是有問題,可以請求CA證書的供應商或者云供應商的技術人員幫你看看,一般都是會配合你解決的,我的開始也是折騰了他們一會,最后也莫名其妙的可以了。
最后成功后,在Chrome瀏覽器里面打開地址就有綠色的標志了。



由于目前我的API平臺還在搭建完善中,因此這個域名展示還是沒有東西可以展示的。
最后的構架會如前面Web API框架圖所示,做到一個統一的整合方案里面。



由于Web API層作為一個公共的接口層,我們就很好保證了各個界面應用層的數據一致性,如果考慮到響應式的集成處理,我們甚至可以把微信應用、APP應用、Web應用做層一套Web程序,即使為了利用各自應用的特殊性,也可以把這些應用做的很相似,這樣就給用戶提供了一個統一的界面表示方式,極大提高客戶使用的界面體驗效果,用戶幾乎不需要額外的界面學習,就可以熟悉整個應用體系的各個模塊使用。

從上面的架構分析來看,我們的Web API作為核心層,可以在上面開發我們各種企業業務應用,

在目前比較熱門的會員管理、客戶管理等方面,結合微信的應用催化劑,就可以做的更加符合移動的潮流,從而實現我們“互聯網+”的應用落地。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,739評論 6 534
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,634評論 3 419
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事?!?“怎么了?”我有些...
    開封第一講書人閱讀 176,653評論 0 377
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,063評論 1 314
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,835評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,235評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,315評論 3 442
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,459評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,000評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,819評論 3 355
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,004評論 1 370
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,560評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,257評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,676評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,937評論 1 288
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,717評論 3 393
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,003評論 2 374

推薦閱讀更多精彩內容