摘要：前言協(xié)議和加密是前端可能會接觸到的加密所以我就將他們進行了一個歸納原理就是在加入層是安全的基礎協(xié)議是在基礎上加了協(xié)議使用端口是端口由網(wǎng)景公司開發(fā)并內置在瀏覽器中作用建立一個信息安全通道來保證數(shù)據(jù)傳輸?shù)陌踩_認網(wǎng)站的真實性可以查看網(wǎng)站認證的真

https,SSH協(xié)議和MD5加密是前端可能會接觸到的加密,所以我就將他們進行了一個歸納.

A.就是在http加入SSL層,是http安全的基礎;
B.htts協(xié)議是在http基礎上加了SSL協(xié)議;
C.使用443端口,http是80端口;
D.由網(wǎng)景公司開發(fā)并內置在瀏覽器中;

A.建立一個信息安全通道,來保證數(shù)據(jù)傳輸?shù)陌踩?
B.確認網(wǎng)站的真實性,可以查看網(wǎng)站認證的真實性;

A.位置:是一個安全套層,是介于TCP?IP之間;
B.分類:
SSL記錄協(xié)議:建立在TCP之上,為數(shù)據(jù)提供數(shù)據(jù)封裝、壓縮、加密;
SSL握手協(xié)議:建立在記錄之上,數(shù)據(jù)傳輸之前雙方的身份驗證、協(xié)商加密算法、交換密鑰;
C.SSL服務器認證過程:
客戶端發(fā)送請求
服務器判斷是否需要生成新主密鑰,需要則返回
客戶端收到信息,產生一個主密鑰,并用公鑰加密傳輸
服務器恢復該主密鑰,并返回一個認證信息

A.SSL協(xié)議包括:握手(憑證交換和驗證)和記錄協(xié)議(數(shù)據(jù)進行加密);
B.SSL握手協(xié)議過程:
1.客服端發(fā)送SSL的版本號,算法種類,產生的隨機數(shù)等;
2.服務器發(fā)送服務器的SSL協(xié)議的版本號,算法種類和證書(里面有公鑰);
3.客服端驗證;
4.驗證通過隨機產生對稱密碼,公鑰加密產生預主密碼,傳輸給服務器;
5.服務器可以要求驗證身份,包括客戶證書和簽名隨機數(shù);
6.驗證通過:服務器用私鑰解開密碼,對稱密鑰產生;
7.客服端發(fā)信息確認后面數(shù)據(jù)采用該通訊;
8.服務器端回應
C.整個過程涉及到3次請求,3次響應

這個可能更多是后臺技術,所以我在這里貼一個鏈接,如果想了解的可以進去看:
如何申請https證書、搭建https網(wǎng)站

非對稱性加密,包括傳輸層,用戶認證和連接協(xié)議

A,在a計算機中產生一對公鑰和私鑰
B,私鑰不動,把公鑰發(fā)送給計算機b,公鑰很復雜,就算過程被竊取,第三方不懂什么意思
C,a和b首次進行嘗試通訊,a發(fā)送的內容通過a存放的私鑰進行加密,在網(wǎng)絡中進行密文件傳輸
D,b也會對該端內容使用公鑰解密,如果能兩臺計算機就結成親密關系
E,以后a和b發(fā)送消息用私鑰和公鑰進行數(shù)據(jù)加密解密操作

比較常見一個應用是和github建立一個友好關系
A.本地生成密鑰:ssh-keygen -t rsa
B.密鑰生成再c盤,將公鑰方法github中,然后下次通訊就可以用SSH通訊
使用ssh連接gitHub

信息摘要算法

A.MD5加密輸出是32位字符串;
B.相同的內容使用MD5加密后,得到的內容一樣的;
C.MD5無法反向解密,唯一就是暴力碰撞破解(就是試32位密碼);
D.為了防止暴力破解,可以加鹽處理;
E.這個應該就是前端用的比較多的對數(shù)據(jù)加密的方式;

A.下載 npm i -S blueimp-md5;
B.引包
C.加密方式:
普通加密:var val=md5("value");
加鹽:var val=md5("value","這是第一次加鹽處理");

1.SSL是一個獨立的安全套層加密協(xié)議;
位于TCP(應用層)和IP(網(wǎng)絡層)之間;
只是起到將數(shù)據(jù)加密和驗證作用;
2.SSH有加密,連接和認證功能,也是一種協(xié)議;
3.md5只是簡單講數(shù)據(jù)加密傳輸或者被存貯到數(shù)據(jù)庫;
4.最本質的區(qū)別:SSL,SSH是一個協(xié)議,而md5是一種數(shù)據(jù)加密方式;

剛開始由于自己題目定義有錯誤,在這里感謝@暮塵Pluto @Nitron @cevin提出的建議,現(xiàn)在已經(jīng)對文章標題進行了修改.
很開心你還能看到這里,歡迎交流,這種一般面試會問到,可以先收藏著.

參考文章:使用ssh連接gitHub
如何申請https證書、搭建https網(wǎng)站