專注於Java領域優質技術號，歡迎關注

內容大綱.png

目的

面試很多時候都會問一些通用的東西，比如多線程,比如數據加密,比如HTTPS,換句話說,無論你從事前端還是後端,數據加密和HTTPS都是必須掌握的

數據加密

首先,我們為什麼要數據加密?因為HTTP所有訪問都是明文的,只要能監聽到網絡所有的請求數據都是透明的,比如任何瀏覽器的開發者工具就能很清楚的看到表單提交的參數和地址,在Android和iOS中也經常通過抓包的方式高仿其他的APP,比如Charles就是Mac上常用的抓包工具

表單加密傳輸

由於篇幅有限,這裡就暫時拿JS舉例

比如我們平時使用的JS插件,凡是.min結尾的,裡面的代碼都是混亂的,如圖:

這些JS都是經過壓縮的,他就是把註釋和空格去掉,把變量名變成短變量名,使得我們閱讀起來就很困難了.

其實目前沒有絕對的安全,因為安全本來就是一場攻防戰,我們能做的,只能是加大解密的成本來防止解密,例如我們可以使用JS混淆,如圖:

從這裡就可以看出,一段簡單的代碼加密壓縮後就變得如此複雜.但是細心的同學就發現,旁邊還有個解密的按鈕呢,所以這種方式的缺陷就在於,這種加密方式是可逆的,一旦得到了加密的JS,就能解密

對稱加密算法

此時回憶一下,我們之前是怎麼加密的?我們都是前臺根據一定規則加密,後臺又根據這個規則解密.那麼我們有沒有辦法做得更安全一點?

辦法是有的,比如我們加密的時候,向後臺請求一個隨機數,而這個隨機數,就作為前臺加密和後臺解密的鑰匙,我們把這個,稱之為密鑰

我們用一張圖來描述一下這個過程:

從序號3我們知道,只要拿不到隨機數(密鑰),那麼將無法解密,但是萬一別人就是能拿到呢?所以,這個對稱加密最大的難點就在於,怎麼有效的隱藏密鑰,以及後臺怎麼管理這個密鑰池

非對稱加密算法

非對稱加密算法是我們平時用的最多的,那麼什麼是非對稱加密算法呢?

我們這麼設想,有沒有一種算法加密過後,用逆向的解密是解不出來的?也就是比如原來的密碼是123,我們的加密算法是每一位+1,也就是變成了234,然後得到234後,我們每一位減一卻得不到123,而是需要另一種算法才能算出123

從上面這個例子我們知道,這個加密算法和解密算法完全就是兩碼事,這種加密的思想,就是非對稱加密算法的一種方式

另一種方式,也就是我們用得最多的,其中這個非對稱,就體現在鑰匙上面,之前我們的對稱加密算法,缺陷就是,前臺和後臺拿到的鑰匙是一樣的

非對稱加密算法採用公鑰/私鑰的方式,使用加密算法(明文,公鑰)生成密文,這個密文,就算知道了公鑰和加密算法,也沒辦法解密,必須要這個公鑰對應的私鑰才能解密.

也就是說,公鑰加密的,只能靠私鑰解密.私鑰加密的,也只能靠公鑰解密,所以我們的公鑰可以隨意向外公佈,只需要隱藏好私鑰即可,具體實現如圖

所以,這種加密算法的缺陷在於,只要拿到了私鑰,所有的密文都能解開

非對稱加密算法中,RSA加密算法用得也比較多,RSA是由創建者的名字首字母組成的,由於篇幅有限,這裡不過多介紹.

HTTPS

HTTPS簡單介紹

HTTPS相信大家都不會陌生,那麼怎麼認識HTTPS呢,我們從三個方面入手,也就是是什麼,有什麼用,為什麼需要

是什麼:

有什麼用:

為什麼需要

HTTPS的工作原理

HTTPS的工作原理.png

文字解讀:

• 瀏覽器(客戶端)將自己支持的一套加密規則(SSL版本號,加密算法版本,哈希算法版本)發送給網站,網站接收到瀏覽器支持的算法版本,選擇一組對應的算法版本
• 網站把網站地址,加密公鑰,證書頒發結構等信息以SSL證書的形式發送給客戶端
• 客戶端接收網站發送的證書後,需要驗證該證書的合法性:從底層的SSL證書向上層證書進行驗證,只要在證書鏈中任意一級證書是可信的,那麼這個證書是可信的
• 得到SSL證書中的域名,和當前訪問網站進行比對,比對通過,瀏覽器信任該站點
• 瀏覽器生成一個隨機數:random,並使用證書中的公鑰進行加密(非對稱算法),偽代碼如:RSA(SSL證書中的公鑰,random)->密文A
• 瀏覽器生成一個握手信息,如:"toby", 並使用確定的HASH算法生成一個hash值,偽代碼如:HASH("toby")->hash碼
• 使用random對toby握手信息進行加密(對稱算法),偽代碼如:encore(random,"toby")->密文B
• 把密文A,hash碼,密文B全部傳給網站
• 服務器接收到密文A、hash碼、密文B後,使用服務器端SSL證書中的密鑰對密文A進行解密,偽代碼如:RSA(SSL證書中的密鑰,密文A)->random
• 使用加密算法對密文B進行解密,偽代碼如decode(random,密文B)->握手信息
• 再用hash算法算出握手信息的hash值,偽代碼如HASH(握手信息)->hash碼
• 對比這個hash碼和傳過來的hash碼是否一致,如果一致,服務器端再生成一個握手信息比如"hello"對服務器端的一個握手信息進行加密,偽代碼如encode(random,"hello")->密文
• 對握手信息進行hash計算,偽代碼如hash("hello")->hash碼
• 把hash碼和密文傳給瀏覽器
• 客戶端接收到密文和hash碼
• decode(random,密文)->握手信息
• HASH(握手信息)->hash碼
• 對比hash碼,如果一致,隨機碼都互相驗證過,並且都各自存放好了,此時,兩邊都完成了HTTP交互,現在的結果是,客戶端和服務器都有一個random

接下來的請求就全部使用encode(random,明文)進行加密傳輸了,服務器端則使用decode(random,密文)->明文,此時,這個加密算法就是一個對稱加密算法了,這個解析出來的明文就會交給HTTP協議,所以我們應用拿到的是明文

線上充值原理

我一向是都是喜歡先粗暴地上流程圖,如下:

文字解讀:

首先,xx平臺需要和第三方平臺簽訂協議,這樣xx平臺就能得到一個在第三方平臺的賬戶,那麼我們開始充值流程

1.用戶開始在xx平臺進行充值

2.用戶由xx平臺的在線充值界面跳轉到第三方支付平臺,這個時候需要帶上username、password、apikey以便第三方平臺知道我們來自哪個平臺,同時還要帶上一個唯一的id作為交易流水

3.一般有快速支付和網銀支付,這裡拿網銀支付舉例,當點擊網銀支付的時候,跳轉到銀行的轉賬界面,這個時候要注意,這個接口是銀行和第三方支付平臺對接的,所以跳轉的時候還要帶上平臺的唯一標識

4.我們假設轉賬成功,那麼這個時候,錢是轉到了第三方支付平臺,而不是xx平臺

5.第三方平臺需要為銀行提供一個接口,進行回調,告訴第三方支付平臺,流水號的處理結果

6.這個時候,將充值金額累加到xx平臺的賬戶中,但是這個只是虛擬現金流的增加,錢還在第三方支付平臺的銀行賬戶中

7.xx平臺需要為第三方平臺提供一個接口,處理回調,告訴xx平臺,流水號的處理結果

8.假設回調成功狀態,xx平臺將在用戶的賬戶把錢增加,但是這個時候,也只是虛擬現金流的增加,此時錢還是在第三方支付平臺的賬戶

9.第三方支付平臺會在一個結算週期(一般是兩天到三天),他會自動地把這段時間之內交易成功的錢打到xx平臺上

所有第三方支付平臺的原理都是以上流程,所以,對於我們xx平臺而言,只需要做兩件事

• 頁面跳轉,把充值信息告訴第三方支付平臺
• 寫一個回調的接口,接收交易情況

閱讀更多 Java技術架構 的文章

關鍵字: 加密傳輸 算法 iOS