• <ul id="cgeq2"></ul>
  • 歡迎您光臨深圳塔燈網(wǎng)絡(luò)科技有限公司!
    電話圖標(biāo) 余先生:13699882642

    網(wǎng)站百科

    為您解碼網(wǎng)站建設(shè)的點(diǎn)點(diǎn)滴滴

    Https詳解

    發(fā)表日期:2018-01 文章編輯:小燈 瀏覽次數(shù):73450

    協(xié)議

    1、HTTP 協(xié)議(HyperText Transfer Protocol,超文本傳輸協(xié)議):是客戶端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議 。

    2、HTTPS 協(xié)議(HyperText Transfer Protocol over Secure Socket Layer):可以理解為HTTP+SSL/TLS, 即 HTTP 下加入 SSL 層,HTTPS 的安全基礎(chǔ)是 SSL,因此加密的詳細(xì)內(nèi)容就需要 SSL,用于安全的 HTTP 數(shù)據(jù)傳輸。


    https.jpg

    如上圖所示 HTTPS 相比 HTTP 多了一層 SSL/TLS

    SSL(Secure Socket Layer,安全套接字層):1994年為 Netscape 所研發(fā),SSL 協(xié)議位于 TCP/IP 協(xié)議與各種應(yīng)用層協(xié)議之間,為數(shù)據(jù)通訊提供安全支持。

    TLS(Transport Layer Security,傳輸層安全):其前身是 SSL,它最初的幾個(gè)版本(SSL 1.0、SSL 2.0、SSL 3.0)由網(wǎng)景公司開發(fā),1999年從 3.1 開始被 IETF 標(biāo)準(zhǔn)化并改名,發(fā)展至今已經(jīng)有 TLS 1.0、TLS 1.1、TLS 1.2 三個(gè)版本。SSL3.0和TLS1.0由于存在安全漏洞,已經(jīng)很少被使用到。TLS 1.3 改動(dòng)會(huì)比較大,目前還在草案階段,目前使用最廣泛的是TLS 1.1、TLS 1.2。

    加密算法:

    據(jù)記載,公元前400年,古希臘人就發(fā)明了置換密碼;在第二次世界大戰(zhàn)期間,德國(guó)軍方啟用了“恩尼格瑪”密碼機(jī),所以密碼學(xué)在社會(huì)發(fā)展中有著廣泛的用途。

    1、對(duì)稱加密
    有流式、分組兩種,加密和解密都是使用的同一個(gè)密鑰。
    例如:DES、AES-GCM、ChaCha20-Poly1305等

    2、非對(duì)稱加密
    加密使用的密鑰和解密使用的密鑰是不相同的,分別稱為:公鑰、私鑰,公鑰和算法都是公開的,私鑰是保密的。非對(duì)稱加密算法性能較低,但是安全性超強(qiáng),由于其加密特性,非對(duì)稱加密算法能加密的數(shù)據(jù)長(zhǎng)度也是有限的。
    例如:RSA、DSA、ECDSA、 DH、ECDHE

    3、哈希算法
    將任意長(zhǎng)度的信息轉(zhuǎn)換為較短的固定長(zhǎng)度的值,通常其長(zhǎng)度要比信息小得多,且算法不可逆。
    例如:MD5、SHA-1、SHA-2、SHA-256 等

    4、數(shù)字簽名
    簽名就是在信息的后面再加上一段內(nèi)容(信息經(jīng)過(guò)hash后的值),可以證明信息沒(méi)有被修改過(guò)。hash值一般都會(huì)加密后(也就是簽名)再和信息一起發(fā)送,以保證這個(gè)hash值不被修改。

    詳解

    一、HTTP 訪問(wèn)過(guò)程

    HTTP 訪問(wèn)過(guò)程

    抓包如下:

    抓包

    如上圖所示,HTTP請(qǐng)求過(guò)程中,客戶端與服務(wù)器之間沒(méi)有任何身份確認(rèn)的過(guò)程,數(shù)據(jù)全部明文傳輸,“裸奔”在互聯(lián)網(wǎng)上,所以很容易遭到黑客的攻擊,如下:

    v2-831635f04f3732e866af0ec6ce1040e7_hd.jpg

    可以看到,客戶端發(fā)出的請(qǐng)求很容易被黑客截獲,如果此時(shí)黑客冒充服務(wù)器,則其可返回任意信息給客戶端,而不被客戶端察覺(jué),所以我們經(jīng)常會(huì)聽到一詞“劫持”,現(xiàn)象如下:

    下面兩圖中,瀏覽器中填入的是相同的URL,左邊是正確響應(yīng),而右邊則是被劫持后的響應(yīng)

    v2-299b4a71f9b005fa15fbcd4cabfd841b_hd.jpg

    所以 HTTP 傳輸面臨的風(fēng)險(xiǎn)有:

    (1) 竊聽風(fēng)險(xiǎn):黑客可以獲知通信內(nèi)容。
    (2) 篡改風(fēng)險(xiǎn):黑客可以修改通信內(nèi)容。
    (3) 冒充風(fēng)險(xiǎn):黑客可以冒充他人身份參與通信。

    二、HTTP 向 HTTPS 演化的過(guò)程

    第一步:為了防止上述現(xiàn)象的發(fā)生,人們想到一個(gè)辦法:對(duì)傳輸?shù)男畔⒓用埽词购诳徒孬@,也無(wú)法破解)

    如上圖所示,此種方式屬于對(duì)稱加密,雙方擁有相同的密鑰,信息得到安全傳輸,但此種方式的缺點(diǎn)是:
    (1)不同的客戶端、服務(wù)器數(shù)量龐大,所以雙方都需要維護(hù)大量的密鑰,維護(hù)成本很高
    (2)因每個(gè)客戶端、服務(wù)器的安全級(jí)別不同,密鑰極易泄露

    第二步:既然使用對(duì)稱加密時(shí),密鑰維護(hù)這么繁瑣,那我們就用非對(duì)稱加密試試

    如上圖所示,客戶端用公鑰對(duì)請(qǐng)求內(nèi)容加密,服務(wù)器使用私鑰對(duì)內(nèi)容解密,反之亦然,但上述過(guò)程也存在缺點(diǎn):

    (1)公鑰是公開的(也就是黑客也會(huì)有公鑰),所以第 ④ 步私鑰加密的信息,如果被黑客截獲,其可以使用公鑰進(jìn)行解密,獲取其中的內(nèi)容

    第三步:非對(duì)稱加密既然也有缺陷,那我們就將對(duì)稱加密,非對(duì)稱加密兩者結(jié)合起來(lái),取其精華、去其糟粕,發(fā)揮兩者的各自的優(yōu)勢(shì)

    如上圖所示

    (1)第 ③ 步時(shí),客戶端說(shuō):(咱們后續(xù)回話采用對(duì)稱加密吧,這是對(duì)稱加密的算法和對(duì)稱密鑰)這段話用公鑰進(jìn)行加密,然后傳給服務(wù)器
    (2)服務(wù)器收到信息后,用私鑰解密,提取出對(duì)稱加密算法和對(duì)稱密鑰后,服務(wù)器說(shuō):(好的)對(duì)稱密鑰加密
    (3)后續(xù)兩者之間信息的傳輸就可以使用對(duì)稱加密的方式了

    遇到的問(wèn)題:

    (1)客戶端如何獲得公鑰
    (2)如何確認(rèn)服務(wù)器是真實(shí)的而不是黑客

    第四步:獲取公鑰與確認(rèn)服務(wù)器身份

    1、獲取公鑰

    (1)提供一個(gè)下載公鑰的地址,回話前讓客戶端去下載。(缺點(diǎn):下載地址有可能是假的;客戶端每次在回話前都先去下載公鑰也很麻煩)
    (2)回話開始時(shí),服務(wù)器把公鑰發(fā)給客戶端(缺點(diǎn):黑客冒充服務(wù)器,發(fā)送給客戶端假的公鑰)

    2、那有木有一種方式既可以安全的獲取公鑰,又能防止黑客冒充呢? 那就需要用到終極武器了:SSL 證書(申購(gòu))

    如上圖所示,在第 ② 步時(shí)服務(wù)器發(fā)送了一個(gè)SSL證書給客戶端,SSL 證書中包含的具體內(nèi)容有:

    (1)證書的發(fā)布機(jī)構(gòu)CA
    (2)證書的有效期
    (3)公鑰
    (4)證書所有者
    (5)簽名

    ………

    3、客戶端在接受到服務(wù)端發(fā)來(lái)的SSL證書時(shí),會(huì)對(duì)證書的真?zhèn)芜M(jìn)行校驗(yàn),以瀏覽器為例說(shuō)明如下:

    (1)首先瀏覽器讀取證書中的證書所有者、有效期等信息進(jìn)行一一校驗(yàn)
    (2)瀏覽器開始查找操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu)CA,與服務(wù)器發(fā)來(lái)的證書中的頒發(fā)者CA比對(duì),用于校驗(yàn)證書是否為合法機(jī)構(gòu)頒發(fā)
    (3)如果找不到,瀏覽器就會(huì)報(bào)錯(cuò),說(shuō)明服務(wù)器發(fā)來(lái)的證書是不可信任的。
    (4)如果找到,那么瀏覽器就會(huì)從操作系統(tǒng)中取出 頒發(fā)者CA 的公鑰,然后對(duì)服務(wù)器發(fā)來(lái)的證書里面的簽名進(jìn)行解密
    (5)瀏覽器使用相同的hash算法計(jì)算出服務(wù)器發(fā)來(lái)的證書的hash值,將這個(gè)計(jì)算的hash值與證書中簽名做對(duì)比
    (6)對(duì)比結(jié)果一致,則證明服務(wù)器發(fā)來(lái)的證書合法,沒(méi)有被冒充
    (7)此時(shí)瀏覽器就可以讀取證書中的公鑰,用于后續(xù)加密了

    4、所以通過(guò)發(fā)送SSL證書的形式,既解決了公鑰獲取問(wèn)題,又解決了黑客冒充問(wèn)題,一箭雙雕,HTTPS加密過(guò)程也就此形成

    所以相比HTTP,HTTPS 傳輸更加安全

    (1) 所有信息都是加密傳播,黑客無(wú)法竊聽。
    (2) 具有校驗(yàn)機(jī)制,一旦被篡改,通信雙方會(huì)立刻發(fā)現(xiàn)。
    (3) 配備身份證書,防止身份被冒充。

    Https通信詳解

    客戶端發(fā)出握手請(qǐng)求(Client Hello),包含以下信息:

    • 支持的協(xié)議版本,比如TLS 1.0版。
    • 一個(gè)客戶端生成的隨機(jī)數(shù)(random_1),這個(gè)隨機(jī)數(shù)既需要客戶端保存又需要發(fā)送給服務(wù)器。
    • 支持的加密方法,比如RSA公鑰加密。
    • 支持的壓縮方法。

    服務(wù)器回復(fù)(Server Hello),包含以下信息:

    • 確認(rèn)使用的加密通信協(xié)議版本,比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致,服務(wù)器關(guān)閉加密通信。
    • 一個(gè)服務(wù)器生成的隨機(jī)數(shù)(random_2)。
    • 確認(rèn)使用的加密方法,比如RSA公鑰加密。
    • 服務(wù)器證書。
    • 如果服務(wù)器需要確認(rèn)客戶端的身份,就會(huì)再包含一項(xiàng)請(qǐng)求,要求客戶端提供”客戶端證書”。比如,金融機(jī)構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò),就會(huì)向正式客戶提供USB密鑰,里面就包含了一張客戶端證書。

    客戶端回應(yīng),包含以下步驟:

    • 驗(yàn)證服務(wù)器證書的合法性,證書合法性包括:證書是否過(guò)期,發(fā)行服務(wù)器證書的 CA 是否可靠,發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”,服務(wù)器證書上的域名是否和服務(wù)器的實(shí)際域名相匹配。如果合法性驗(yàn)證沒(méi)有通過(guò),通訊將斷開;
    • 客戶端使用一些加密算法(例如:RSA,Diffie-Hellman)產(chǎn)生一個(gè)48個(gè)字節(jié)的Key,這個(gè)Key叫PreMaster Secret。該P(yáng)reMaster Secret用服務(wù)器公鑰加密傳送,防止被竊聽。
    • 編碼改變通知,表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
    • 客戶端握手結(jié)束通知,表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值,用來(lái)供服務(wù)器校驗(yàn)。
    • 如果前一步,服務(wù)器要求客戶端證書,客戶端會(huì)在這一步發(fā)送證書及相關(guān)信息。

    服務(wù)器回應(yīng),服務(wù)器通過(guò)上面的三個(gè)隨機(jī)數(shù)(random_1,random_2,PreMaster Secret),計(jì)算出本次會(huì)話的『會(huì)話密鑰(session secret)』,然后向客戶端發(fā)送下面信息

    • 編碼改變通知,表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
    • 服務(wù)器握手結(jié)束通知,表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值,用來(lái)供客戶端校驗(yàn)。

    至此,服務(wù)器和客戶端的握手階段全部結(jié)束,接下來(lái),客戶端與服務(wù)器進(jìn)入加密通信,就完全是使用普通的HTTP協(xié)議,只不過(guò)用『會(huì)話密鑰(session secret)』對(duì)內(nèi)容做對(duì)稱加密。

    PreMaster Secret 說(shuō)明
    PreMaster secret是在客戶端使用RSA或者Diffie-Hellman等加密算法生成的。它將用來(lái)跟服務(wù)端和客戶端在Hello階段產(chǎn)生的隨機(jī)數(shù)結(jié)合在一起生成Master secret。在客戶端使用服務(wù)單的公鑰對(duì)PreMaster secret進(jìn)行加密之后傳送給服務(wù)端,服務(wù)端將使用私鑰進(jìn)行解密得到PreMaster secret。也就是說(shuō)服務(wù)端和客戶端都有一份相同的PreMaster secret和隨機(jī)數(shù)。

    關(guān)于Master Secret的計(jì)算
    至于為什么一定要用三個(gè)隨機(jī)數(shù),來(lái)生成Master Secret,由于SSL協(xié)議中證書是靜態(tài)的,因此需要引入一種隨機(jī)因素來(lái)保證協(xié)商出來(lái)的密鑰的隨機(jī)性。SSL協(xié)議不信任每個(gè)主機(jī)都能生成完全隨機(jī)的隨機(jī)數(shù),所以這里需要服務(wù)器和客戶端共生成3個(gè)隨機(jī)數(shù),每增加一個(gè)自由度,隨機(jī)性就會(huì)相應(yīng)增加。

    同時(shí)需要注意前兩個(gè)隨機(jī)數(shù)都是明文傳輸?shù)模`聽者是可以輕易獲取到的,只有最后一個(gè) PreMaster Secret 是加密傳輸?shù)模挥袚碛蟹?wù)器私鑰才能解密,一旦 PreMaster Secret 泄露,那么本次通信就就完全可被破解了。

    對(duì)稱加密 & 非對(duì)稱加密

    HTTPS 的通信過(guò)程中只在握手階段使用了非對(duì)稱加密,后面的通信過(guò)程均使用的對(duì)稱加密。盡管非對(duì)稱加密相比對(duì)稱加密更加安全,但也存在兩個(gè)明顯缺點(diǎn):

    • CPU 計(jì)算資源消耗非常大。一次完全 TLS 握手,密鑰交換時(shí)的非對(duì)稱解密計(jì)算量占整個(gè)握手過(guò)程的 90% 以上。而對(duì)稱加密的計(jì)算量只相當(dāng)于非對(duì)稱加密的 0.1%,如果應(yīng)用層數(shù)據(jù)也使用非對(duì)稱加解密,性能開銷太大,無(wú)法承受。
    • 非對(duì)稱加密算法對(duì)加密內(nèi)容的長(zhǎng)度有限制,不能超過(guò)公鑰長(zhǎng)度。比如現(xiàn)在常用的公鑰長(zhǎng)度是 2048 位,意味著待加密內(nèi)容不能超過(guò) 256 個(gè)字節(jié)。

    所以公鑰加密目前只能用來(lái)作密鑰交換或者內(nèi)容簽名,不適合用來(lái)做應(yīng)用層傳輸內(nèi)容的加解密。
    非對(duì)稱密鑰交換算法是整個(gè) HTTPS 得以安全的基石,充分理解非對(duì)稱密鑰交換算法是理解 HTTPS 協(xié)議和功能的關(guān)鍵。

    安全性

    針對(duì) HTTPS 的攻擊最主要的就是 SSL 劫持攻擊,其分為兩種:

    HTTPS 替換為 HTTP

    這種方式就是攻擊者充當(dāng)中間人和服務(wù)器通信,然后把相應(yīng)的通信內(nèi)容通過(guò) HTTP 協(xié)議發(fā)送給客戶端,由于 HTTP 協(xié)議是未加密的,于是就可以截獲用戶的訪問(wèn)數(shù)據(jù)。

    這種攻擊方式比較簡(jiǎn)單,通過(guò)代理,可以很容易的把 HTTPS 變成 HTTP,這個(gè)一方面需要用戶留意網(wǎng)站是否有從 HTTPS 跳轉(zhuǎn)到 HTTP 的行為,另一方面服務(wù)器也可以通過(guò)配置將所有HTTP的請(qǐng)求強(qiáng)制轉(zhuǎn)移到HTTPS上。

    HTTPS 劫持

    這種方式攻擊者為了獲得 HTTPS 的明文傳輸內(nèi)容,需要充當(dāng)中間人,替換服務(wù)器發(fā)給用戶的包含公鑰的證書。攻擊者既和用戶之間建立了 HTTPS 鏈接,又和服務(wù)器建立了 HTTPS 鏈接。

    在上面握手建立的過(guò)程中,由于用戶的公鑰是攻擊者生成的,所以攻擊者可以輕易獲得握手中的數(shù)據(jù)。也就可以獲取到和用戶通信過(guò)程中的對(duì)稱加密的密鑰,攻擊者可以通過(guò)密鑰獲取用戶發(fā)送的數(shù)據(jù),同時(shí)在使用和服務(wù)器通信的密鑰加密后再發(fā)送給服務(wù)器。

    這種攻擊方式也有一個(gè)明顯的問(wèn)題就是攻擊者生成的證書幾乎是不可能被用戶信任的,在這種情況下,用戶瀏覽器通常會(huì)提示該網(wǎng)站的證書不可信,是否繼續(xù)訪問(wèn),這已經(jīng)對(duì)用戶進(jìn)行了一個(gè)明顯的警告了。

    另外我們也可以通過(guò)這種對(duì)基于 HTTPS 的通信進(jìn)行抓包分析。Mac 平臺(tái)著名的抓包工具 Charles 就是基于這種方式,首先要求你信任一個(gè)它的證書,然后自己充當(dāng)中間人對(duì)你與某個(gè)服務(wù)器的 HTTPS 通信進(jìn)行抓包分析。

    總結(jié)

    Http請(qǐng)求是明文通訊的,所有信息可以通過(guò)中間人,代理一覽無(wú)遺, 所以我們需要一種加密后的通訊機(jī)制, 探索過(guò)程中有下面幾種方案:

    1. 對(duì)稱加密,客戶端和服務(wù)器端都維護(hù)相同的密鑰,對(duì)內(nèi)容進(jìn)行加密解密,缺點(diǎn)是雙方都需要維護(hù)大量的密鑰,維護(hù)成本很高, 而且他們的安全性不同,很容易就會(huì)泄漏。
    2. 非對(duì)稱加密,客戶端使用公鑰加密內(nèi)容,服務(wù)器使用私鑰解密,缺點(diǎn)是客戶端的公鑰是公開的,很容易暴露給黑客。
    3. 非對(duì)稱加密和對(duì)稱加密結(jié)合

    客戶端發(fā)出握手請(qǐng)求(Client Hello):

    • 支持的協(xié)議版本,比如TLS 1.0版。
    • 一個(gè)客戶端生成的隨機(jī)數(shù)(random_1)
    • 支持的加密方法,比如RSA公鑰加密。

    服務(wù)器回復(fù)(Server Hello):

    • 確認(rèn)協(xié)議版本, 比如TLS 1.0版。
    • 生成一個(gè)隨機(jī)數(shù)random_2,發(fā)給客戶端
    • 確定加密方法,比如RSA
    • 服務(wù)器證書。(包括公鑰,證書各種信息)

    客戶端回應(yīng):

    • 驗(yàn)證證書各種有效性,包括證書有效期,域名,公鑰是否正確
    • 告訴服務(wù)器端以后對(duì)話使用對(duì)稱加密。
    • 使用一些加密算法(例如:RSA,Diffie-Hellman) 生成一個(gè)PreMaster Secret
    • 使用公鑰加密PreMaster Secret等信息,發(fā)送給服務(wù)器端。(也就是這里使用了非對(duì)稱加密)

    服務(wù)器端回應(yīng)

    • 收到信息后用私鑰解密(也就是這里使用了非對(duì)稱加密)
    • 服務(wù)器通過(guò)上面的三個(gè)隨機(jī)數(shù)(random_1,random_2,PreMaster Secret),計(jì)算出本次會(huì)話的『會(huì)話密鑰(session secret)』
    • 服務(wù)器端開始用session secret開始對(duì)稱加密返回加密方法和密鑰發(fā)送給客戶端

    參考:

    HTTPS詳解
    HTTPS干貨


    本頁(yè)內(nèi)容由塔燈網(wǎng)絡(luò)科技有限公司通過(guò)網(wǎng)絡(luò)收集編輯所得,所有資料僅供用戶學(xué)習(xí)參考,本站不擁有所有權(quán),如您認(rèn)為本網(wǎng)頁(yè)中由涉嫌抄襲的內(nèi)容,請(qǐng)及時(shí)與我們聯(lián)系,并提供相關(guān)證據(jù),工作人員會(huì)在5工作日內(nèi)聯(lián)系您,一經(jīng)查實(shí),本站立刻刪除侵權(quán)內(nèi)容。本文鏈接:http://www.juherenli.com/20443.html
    相關(guān)開發(fā)語(yǔ)言
     八年  行業(yè)經(jīng)驗(yàn)

    多一份參考,總有益處

    聯(lián)系深圳網(wǎng)站公司塔燈網(wǎng)絡(luò),免費(fèi)獲得網(wǎng)站建設(shè)方案及報(bào)價(jià)

    咨詢相關(guān)問(wèn)題或預(yù)約面談,可以通過(guò)以下方式與我們聯(lián)系

    業(yè)務(wù)熱線:余經(jīng)理:13699882642

    Copyright ? 2013-2018 Tadeng NetWork Technology Co., LTD. All Rights Reserved.    

    • QQ咨詢
    • 在線咨詢
    • 官方微信
    • 聯(lián)系電話
      座機(jī)0755-29185426
      手機(jī)13699882642
    • 預(yù)約上門
    • 返回頂部
    亚洲国产午夜精品理论片| 亚洲av午夜精品一区二区三区 | 国内精品久久久久影院一蜜桃| 精品无码专区亚洲| 精品无码久久久久久尤物| 久久精品国产亚洲AV不卡| 精品国产电影久久九九| 亚拍精品一区二区三区| 久久老子午夜精品无码怎么打| 亚洲午夜国产精品无码老牛影视| 国产精品国产三级国产专播下| 2022国产成人福利精品视频| 久久99国产精品成人| 国产在线观看一区精品| 精品一区二区三区在线视频观看| 精品熟女少妇AV免费观看| 亚洲区精品久久一区二区三区| 嫩草影院久久国产精品| 久久精品国产国产精品四凭| 动漫精品专区一区二区三区不卡| 精品国产精品国产| 亚洲午夜精品久久久久久app| 麻豆国产精品免费视频| 久久夜色精品国产噜噜噜亚洲AV | 亚洲精品偷拍无码不卡av| 国产精品熟女一区二区| 国精品产露脸自拍| 亚洲精品无码专区久久同性男| 国产精品R级最新在线观看| 精品无码国产AV一区二区三区| 久久AV无码精品人妻出轨| 伊人无码精品久久一区二区| 热久久视久久精品18| 91精品福利一区二区| 亚洲综合精品成人| 亚洲精品GV天堂无码男同| 国产精品密蕾丝视频| 亚洲精品欧美综合四区| 性虎精品无码AV导航| 久草热8精品视频在线观看| 国产精品视频一区|