一区二区三区欧美日韩-一区二区三区欧美-一区二区三区免费在线视频-一区二区三区免费在线观看-久久精品店-久久精品第一页

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

網(wǎng)站百科

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

iOS HTTPS適配

發(fā)表日期:2017-03 文章編輯:小燈 瀏覽次數(shù):1807

快速適配直接看下面的示例代碼吧,概念有點(diǎn)多。。。

自己客戶端生成證書放在服務(wù)器上,可以自簽
服務(wù)器必須ca簽署,服務(wù)器生成,提供給我們

SSL/TLS協(xié)議運(yùn)行機(jī)制概述
圖解SSL/TLS協(xié)議

一、單向認(rèn)證

HTTPS在建立Socket連接之前,需要進(jìn)行握手。
1.客戶端向服務(wù)器端發(fā)送SSL協(xié)議版本號、加密算法種類、隨機(jī)數(shù)等信息。
2.服務(wù)端給客戶端返回SSL協(xié)議版本號、加密算法種類、隨機(jī)數(shù)等信息,同時(shí)也返回服務(wù)器端的證書,即公鑰證書。
3.客戶端使用服務(wù)端返回的信息驗(yàn)證服務(wù)器的合法性,包括

  • 證書是否過期
  • 發(fā)行服務(wù)器證書的CA是否可靠
  • 返回的公鑰是否能正確解開返回證書中的數(shù)字簽名
  • 服務(wù)器證書上的域名是否和服務(wù)器的實(shí)際域名相匹配
    驗(yàn)證通過后,將繼續(xù)進(jìn)行通信,否則,終止通信

4.客戶端向服務(wù)端發(fā)送自己所能支持的對稱加密方案,供服務(wù)器端進(jìn)行選擇。
5.服務(wù)器端在客戶端提供的加密方案中選擇加密程度最高的加密方式。
6.服務(wù)器將選擇好的加密方案通過明文方式返回給客戶端。
7.客戶端接收到服務(wù)器端返回的加密方式后,使用該加密方式生成產(chǎn)生隨機(jī)碼,用作通信過程中對稱加密的秘鑰,使用服務(wù)器端返回的公鑰進(jìn)行加密,將加密后的隨機(jī)碼發(fā)送至服務(wù)器。
8.服務(wù)器收到客戶端返回的加密信息后,使用自己的私鑰進(jìn)行解密,獲取對稱加密秘鑰。
9.在接下來的會(huì)話中,服務(wù)器和客戶端將會(huì)使用該密碼進(jìn)行對稱加密,保證通信過程中信息的安全。
單向認(rèn)證:保證server是真的,通道是安全的(對稱密鑰);
雙向認(rèn)證:保證client和server是真的,通道是安全的(對稱密鑰);

二、雙向認(rèn)證

為了便于更好的認(rèn)識和理解SSL協(xié)議,這里著重介紹SSL協(xié)議的握手協(xié)議。SSL協(xié)議既用到了公鑰加密技術(shù)又用到了對稱加密技術(shù),對稱加密技術(shù)雖然比公鑰加密技術(shù)的速度快,可是公鑰加密技術(shù)提供了更好的身份認(rèn)證技術(shù)。SSL的握手協(xié)議非常有效的讓客戶和服務(wù)器之間完成相互之間的身份認(rèn)證。
1.客戶的瀏覽器向服務(wù)器傳遞客戶端SSL協(xié)議的版本號,加密算法的種類,產(chǎn)生的隨機(jī)數(shù),以及其他服務(wù)器和客戶端之間通訊所需要的各種信息。
2.服務(wù)器向客戶端傳送SSL協(xié)議的版本號,加密算法的種類,隨機(jī)數(shù)以及其他相關(guān)信息,同時(shí)服務(wù)器還將向客戶端傳送自己的證書。
3.客戶利用服務(wù)器傳過來的信息驗(yàn)證服務(wù)器的合法性,服務(wù)器的合法性包括

  • 證書是否過期
  • 發(fā)行服務(wù)器證書的CA是否可靠
  • 發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”
  • 服務(wù)器證書上的域名是否和服務(wù)器的實(shí)際域名相匹配

如果合法性驗(yàn)證沒有通過,通訊將斷開,如果合法性驗(yàn)證通過,將繼續(xù)進(jìn)行第四步。

4.用戶端隨機(jī)產(chǎn)生一個(gè)用于后面通訊的“對稱密碼”,然后用服務(wù)器的公鑰(服務(wù)器的公鑰從步驟2終端服務(wù)器的證書中獲得)對其加密,然后將加密后的“預(yù)主密碼”傳給服務(wù)器。
5.如果服務(wù)器要求客戶的身份認(rèn)證(在握手過程中為可選),用戶可以建立一個(gè)隨機(jī)數(shù)然后對其進(jìn)行數(shù)據(jù)簽名,將這個(gè)含有簽名的隨機(jī)數(shù)和客戶自己的證書以及加密過的“預(yù)主密碼”一起傳給服務(wù)器。
6.如果服務(wù)器要求客戶的身份認(rèn)證,服務(wù)器必須檢驗(yàn)客戶證書和簽名隨機(jī)數(shù)的合法性,具體的合法性驗(yàn)證過程包括:

  • 客戶的證書使用日期是否有效
  • 為客戶提供證書的CA是否可靠
  • 發(fā)行CA的公鑰能否正確解開客戶證書的發(fā)行CA的數(shù)字簽名
  • 檢查客戶的證書是否在證書廢止列表(CRL)中。

檢驗(yàn)如果沒有通過,通訊立刻中斷;如果驗(yàn)證通過,服務(wù)器將用自己的私鑰解開加密的“預(yù)主密碼”,然后執(zhí)行一系列步驟來產(chǎn)生主通訊密碼(客戶端也將通過同樣的方法產(chǎn)生相同的主通訊密碼)。
7.服務(wù)器和客戶端用相同的主密碼即“通話密碼”,一個(gè)對稱密鑰用于SSL協(xié)議的安全數(shù)據(jù)通訊的加解密通訊。同時(shí)在SSL通訊過程中還要完成數(shù)據(jù)通訊的完整性,防止數(shù)據(jù)通訊中的任何變化。
8.客戶端向服務(wù)器端發(fā)出信息,指明后面的數(shù)據(jù)通訊將使用步驟7中的主密碼為對稱密鑰,同時(shí)通知服務(wù)器客戶端的握手過程結(jié)束。
9.服務(wù)器向客戶端發(fā)出信息,指明后面的數(shù)據(jù)通訊將使用的步驟7中的主密碼為對稱密鑰,同時(shí)通知客戶端服務(wù)器端的握手過程結(jié)束。
10.SSL的握手部分結(jié)束,SSL安全通道的數(shù)據(jù)通訊開始,客戶和服務(wù)器開始使用相同的對稱密鑰進(jìn)行數(shù)據(jù)通訊,同時(shí)進(jìn)行通訊完整性的檢驗(yàn)。

雙向認(rèn)證SSL協(xié)議的具體過程

1.瀏覽器發(fā)送一個(gè)連接請求給安全服務(wù)器。
2.服務(wù)器將自己的證書,以及同證書相關(guān)的信息發(fā)送給客戶瀏覽器。
3.客戶瀏覽器檢查服務(wù)器送過來的證書是否是由自己信賴的CA中心所簽發(fā)的。如果是,就繼續(xù)執(zhí)行協(xié)議;如果不是,客戶瀏覽器就給客戶一個(gè)警告消息:警告客戶這個(gè)證書不是可信賴的,詢問客戶是否需要繼續(xù)。
4.接著客戶瀏覽器比較證書里的消息,例如域名和公鑰,與服務(wù)器剛剛發(fā)送的相關(guān)消息是否一致,如果是一致的,客戶瀏覽器認(rèn)可這個(gè)服務(wù)器合法身份。
5.服務(wù)器要求客戶發(fā)送客戶自己的證書。收到后,服務(wù)器驗(yàn)證客戶的證書,如果沒有通過驗(yàn)證,拒絕連接;如果通過驗(yàn)證,服務(wù)器獲得用戶的公鑰。
6.客戶瀏覽器告訴服務(wù)器自己所能夠支持的通訊對稱密碼方案。
7.服務(wù)器從客戶發(fā)送過來的密碼方案中,選擇一種加密程度最高的密碼方案,用客戶的公鑰加過密后通知瀏覽器。
8.瀏覽器針對這個(gè)密碼方案,選擇一個(gè)通話密鑰,接著用服務(wù)器的公鑰加過密后發(fā)送給服務(wù)器。
9.服務(wù)器接收到瀏覽器送過來的消息,用自己的私鑰解密,獲得通話密鑰。
10.服務(wù)器、瀏覽器接下來的通訊都是用對稱密碼方案,對稱密鑰是加過密的。

上面所述的是雙向認(rèn)證 SSL 協(xié)議的具體通訊過程,這種情況要求服務(wù)器和用戶雙方都有證書。單向認(rèn)證 SSL 協(xié)議不需要客戶擁有 CA 證書,具體的過程相對于上面的步驟,只需將服務(wù)器端驗(yàn)證客戶證書的過程去掉,以及在協(xié)商對稱密碼方案,對稱通話密鑰時(shí),服務(wù)器發(fā)送給客戶的是沒有加過密的 (這并不影響 SSL 過程的安全性)密碼方案。 這樣,雙方具體的通訊內(nèi)容,就是加過密的數(shù)據(jù),如果有第三方攻擊,獲得的只是加密的數(shù)據(jù),第三方要獲得有用的信息,就需要對加密的數(shù)據(jù)進(jìn)行解密,這時(shí)候的 安全就依賴于密碼方案的安全。而幸運(yùn)的是,目前所用的密碼方案,只要通訊密鑰長度足夠的長,就足夠的安全。這也是我們強(qiáng)調(diào)要求使用 128 位加密通訊的原因。

雙向認(rèn)證和單向認(rèn)證原理基本差不多,只是除了客戶端需要認(rèn)證服務(wù)端以外,增加了服務(wù)器端對客戶端的認(rèn)證。

單向認(rèn)證只要求站點(diǎn)部署了SSL證書就行,任何用戶都可以去訪問(IP被限制除外等),只是服務(wù)器端提供了身份認(rèn)證。而雙向認(rèn)證則是需要服務(wù)端需要客戶端提供身份認(rèn)證,只能是服務(wù)端允許的客戶能去訪問,安全性相對要高一些。

一般Web應(yīng)用都是采用單向認(rèn)證的,原因很簡單,用戶數(shù)目廣泛,且無需做在通訊層做用戶身份驗(yàn)證,一般都在應(yīng)用邏輯成來保護(hù)用戶的合法登入。但如果是企業(yè)對應(yīng)對接,情況就不一樣,可能會(huì)要求對客戶端做身份驗(yàn)證。這時(shí)就需要做雙向認(rèn)證。

與單向認(rèn)證的區(qū)別就是產(chǎn)生的是二分之一的對稱密鑰。
即對稱密鑰是client與server各自產(chǎn)生一半。

隨意畫了畫,大家別按我這個(gè)來

HTTPS = HTTP + SSL/TLS + TCP

TLS 是SSL新的別稱
也就是說 TLS 1.0 = SSL 3.1

常用的是下面這些

SSL 2.0
SSL 3.0
TLS 1.0 (SSL 3.1)
TLS 1.1 (SSL 3.1)
TLS 1.2 (SSL 3.1)

使用明文傳播,帶來了三大風(fēng)險(xiǎn)

竊聽風(fēng)險(xiǎn)(eavesdropping):第三方可以獲知通信內(nèi)容。
篡改風(fēng)險(xiǎn)(tampering):第三方可以修改通信內(nèi)容。
冒充風(fēng)險(xiǎn)(pretending):第三方可以冒充他人身份參與通信。

SSL/TLS協(xié)議是為了解決這三大風(fēng)險(xiǎn)而設(shè)計(jì)的,希望達(dá)到:

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

蘋果ATS安全設(shè)置的要求
ATS默認(rèn)的安全要求:

  • 服務(wù)器必須支持傳輸層安全(TLS)協(xié)議1.2以上版本;
  • 通訊加密套件僅限支持完全正向加密的套件;
  • 證書必須使用SHA256或更高的哈希算法簽名;以及2048位以上RSA密鑰或256位以上ECC密鑰。

不滿足以上條件,ATS會(huì)拒絕連接。

方案一:讓公司的服務(wù)端升級使用TLS 1.2

方案二:雖Apple不建議,但可通過在 Info.plist 中聲明,倒退回不安全的網(wǎng)絡(luò)請求依然能讓App訪問指定http,甚至任意的http。

一、準(zhǔn)備工作

申請一個(gè)SSL證書

申請免費(fèi)SSL證書教程

SSL證書按驗(yàn)證的類別可分:

DV SSL證書(域名驗(yàn)證型):只驗(yàn)證域名所有權(quán),適合個(gè)人網(wǎng)站、博客等站點(diǎn)使用;

OV SSL證書(企業(yè)驗(yàn)證型):驗(yàn)證網(wǎng)站所屬單位身份,適合企業(yè)級用戶使用;

EV SSL證書(擴(kuò)展驗(yàn)證型):擴(kuò)展驗(yàn)證網(wǎng)站所屬單位身份,這種證書在瀏覽器中會(huì)顯示醒目的綠色地址欄,可信度最高,適合需要用戶高度信任的企業(yè)級用戶使用。

.crt文件轉(zhuǎn)成.cer文件

二、AFNetworking適配

注:AFNetworking 3.0以上

首先向后臺拿到證書(jks格式/Mac:.cer格式) ,或者你可以打開請求的完整鏈接 在Mac上下載該證書 (導(dǎo)入Xcode工程)

可以去騰訊云申請免費(fèi)的SSL證書

檢測接口是否滿足蘋果的ATS要求,有以下兩種方法:
1.騰訊云提供的檢測頁面檢測
https://www.qcloud.com/product/tools
2.終端輸入 nsurl --ats-diagnostics --verbose 你的接口地址

關(guān)于iOS9中的ATS相關(guān)說明及適配

在info.plist刪掉或改為NO
單向認(rèn)證示例代碼
+ (AFSecurityPolicy *)customSecurityPolicy { // 先導(dǎo)入證書,在這加證書,一般情況適用于單項(xiàng)認(rèn)證 // 證書的路徑 NSString *cerPath = [[NSBundle mainBundle] pathForResource:@"xxx" ofType:@"cer"];NSData *cerData = [NSData dataWithContentsOfFile:cerPath];if (cerData == nil) { return nil; } NSSet *setData = [NSSet setWithObject:cerData]; //AFSSLPinningModeCertificate 使用證書驗(yàn)證模式 AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];// allowInvalidCertificates 是否允許無效證書(也就是自建的證書),默認(rèn)為NO // 如果是需要驗(yàn)證自建證書,需要設(shè)置為YES securityPolicy.allowInvalidCertificates = YES;// validatesDomainName 是否需要驗(yàn)證域名,默認(rèn)為YES; // 假如證書的域名與你請求的域名不一致,需要把該項(xiàng)設(shè)置為NO;如設(shè)成NO的話,即服務(wù)器使用其他可信任機(jī)構(gòu)頒發(fā)的證書,也可以建立連接,這個(gè)非常危險(xiǎn),建議打開。 // 設(shè)置為NO,主要用于這種情況:客戶端請求的事子域名,而證書上的是另外一個(gè)域名。因?yàn)镾SL證書上的域名是獨(dú)立的,假如證書上注冊的域名是www.google.com,那么mail.google.com是無法驗(yàn)證通過的;當(dāng)然有錢可以注冊通配符的域名*.google.com,但這個(gè)還是比較貴的。 // 如設(shè)置為NO,建議自己添加對應(yīng)域名的校驗(yàn)邏輯。 securityPolicy.validatesDomainName = NO;[securityPolicy setPinnedCertificates:setData];return securityPolicy; } 

然后在相應(yīng)位置加入

[manager setSecurityPolicy:[self customSecurityPolicy]]; 

AFNetworking定義了三種SSLpinningmode:
AFSSLPinningModeNone: 代表客戶端無條件地信任服務(wù)器端返回的證書

AFSSLPinningModePublicKey : 代表客戶端會(huì)將服務(wù)器端返回的證書與本地保存的證書PublicKey的部分進(jìn)行校驗(yàn);如果正確,才繼續(xù)進(jìn)行。

AFSSLPinningModeCertificate: 代表客戶端會(huì)將服務(wù)器端返回的證書和本地保存的證書中的所有內(nèi)容,包括PublicKey和證書部分,全部進(jìn)行校驗(yàn);如果正確,才繼續(xù)進(jìn)行。

雙向認(rèn)證示例代碼

http://blog.csdn.net/guobing19871024/article/details/53841373
http://blog.csdn.net/jerryvon/article/details/8548802

//校驗(yàn)證書 + (void)checkCredential:(AFURLSessionManager *)manager { [manager setSessionDidBecomeInvalidBlock:^(NSURLSession * _Nonnull session, NSError * _Nonnull error) { }]; __weak typeof(manager)weakManager = manager; [manager setSessionDidReceiveAuthenticationChallengeBlock:^NSURLSessionAuthChallengeDisposition(NSURLSession*session, NSURLAuthenticationChallenge *challenge, NSURLCredential *__autoreleasing*_credential) { NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthChallengePerformDefaultHandling; __autoreleasing NSURLCredential *credential =nil; NSLog(@"authenticationMethod=%@",challenge.protectionSpace.authenticationMethod); //判斷是核驗(yàn)客戶端證書還是服務(wù)器證書 if([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) { // 基于客戶端的安全策略來決定是否信任該服務(wù)器,不信任的話,也就沒必要響應(yīng)挑戰(zhàn) if([weakManager.securityPolicy evaluateServerTrust:challenge.protectionSpace.serverTrust forDomain:challenge.protectionSpace.host]) { // 創(chuàng)建挑戰(zhàn)證書(注:挑戰(zhàn)方式為UseCredential和PerformDefaultHandling都需要新建挑戰(zhàn)證書) NSLog(@"serverTrust=%@",challenge.protectionSpace.serverTrust); credential = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust]; // 確定挑戰(zhàn)的方式 if (credential) { //證書挑戰(zhàn)設(shè)計(jì)policy,none,則跑到這里 disposition = NSURLSessionAuthChallengeUseCredential; } else { disposition = NSURLSessionAuthChallengePerformDefaultHandling; } } else { disposition = NSURLSessionAuthChallengeCancelAuthenticationChallenge; } } else { // client authentication SecIdentityRef identity = NULL; SecTrustRef trust = NULL; NSString *p12 = [[NSBundle mainBundle] pathForResource:@"xxx"ofType:@"p12"]; NSFileManager *fileManager =[NSFileManager defaultManager];if(![fileManager fileExistsAtPath:p12]) { NSLog(@"client.p12:not exist"); } else { NSData *PKCS12Data = [NSData dataWithContentsOfFile:p12];if ([self extractIdentity:&identity andTrust:&trust fromPKCS12Data:PKCS12Data]) { SecCertificateRef certificate = NULL; SecIdentityCopyCertificate(identity, &certificate); const void*certs[] = {certificate}; CFArrayRef certArray =CFArrayCreate(kCFAllocatorDefault, certs,1,NULL); credential =[NSURLCredential credentialWithIdentity:identity certificates:(__bridgeNSArray*)certArray persistence:NSURLCredentialPersistencePermanent]; disposition =NSURLSessionAuthChallengeUseCredential; } } } *_credential = credential; return disposition; }]; }//讀取p12文件中的密碼 + (BOOL)extractIdentity:(SecIdentityRef*)outIdentity andTrust:(SecTrustRef *)outTrust fromPKCS12Data:(NSData *)inPKCS12Data { OSStatus securityError = errSecSuccess; //client certificate password NSDictionary *optionsDictionary = [NSDictionary dictionaryWithObject:@"123456" forKey:(__bridge id)kSecImportExportPassphrase];CFArrayRef items = CFArrayCreate(NULL, 0, 0, NULL); securityError = SecPKCS12Import((__bridge CFDataRef)inPKCS12Data,(__bridge CFDictionaryRef)optionsDictionary,&items);if(securityError == 0) { CFDictionaryRef myIdentityAndTrust =CFArrayGetValueAtIndex(items,0); const void*tempIdentity =NULL; tempIdentity= CFDictionaryGetValue (myIdentityAndTrust,kSecImportItemIdentity); *outIdentity = (SecIdentityRef)tempIdentity; const void*tempTrust =NULL; tempTrust = CFDictionaryGetValue(myIdentityAndTrust,kSecImportItemTrust); *outTrust = (SecTrustRef)tempTrust; } else { NSLog(@"Failedwith error code %d",(int)securityError); return NO; } return YES; } 

然后在相應(yīng)位置加入

[manager setSecurityPolicy:[self customSecurityPolicy]]; [self checkCredential:manager];

三、NSURLConnection、NSURLSession適配

http://www.cnblogs.com/lmfboke/p/6232656.html
http://oncenote.com/2014/10/21/Security-1-HTTPS/
http://www.jianshu.com/p/97745be81d64

四、其他

SDWebImage繞過證書驗(yàn)證去加載圖片

[imageView sd_setImageWithURL:[NSURL URLWithString:urlString] placeholderImage:self.placeholder options:SDWebImageAllowInvalidSSLCertificates]; 

五、部分參考

http://www.jianshu.com/p/72bf60b5f94d
http://www.cnblogs.com/lmfboke/p/6232656.html
http://blog.csdn.net/iostiannan/article/details/53763082
http://www.wosign.com/faq/faq-ios-https.htm
http://www.cocoachina.com/ios/20150702/12384.html
http://www.wosign.com/news/ios-app-https.htm
http://www.cocoachina.com/ios/20161207/18308.html
http://edison0663.iteye.com/blog/996526


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

多一份參考,總有益處

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

咨詢相關(guān)問題或預(yù)約面談,可以通過以下方式與我們聯(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ù)約上門
  • 返回頂部
主站蜘蛛池模板: 內射XXX韩国在线观看| 国产扒开美女双腿屁股流白浆 | 国产黄大片在线视频| adc我们的永久网址| 综合亚洲桃色第一影院| 伊人久久大香| 一区不卡二区卡| 亚洲人成色777777老人头| 亚洲精品成人久久久影院| 午夜影视不充值观看| 无码天堂亚洲国产AV久久| 我们中文在线观看免费完整版| 三级黄色在线视频中文| 色多多深夜福利免费观看| 十八禁啪啦啪漫画| 手机精品在线| 迅雷成人论坛| 亚洲狠狠网站色噜噜| 亚洲视频中文字幕在线观看| 亚洲精品色情APP在线下载观看| 亚洲美女视频高清在线看| 亚洲欧洲无码AV在线观看你懂的 | 嫩草影院在线观看精品视频| 美女乱草鲍高清照片| 男女亲吻摸下面吃奶视频| 欧美性FREE玩弄少妇| 日韩人妻少妇一区二区三区| 色偷偷网站| 亚洲 欧美 中文 日韩 视频| 亚洲欧美一区二区久久| 在线免费观看亚洲视频| 97综合久久| 成人毛片免费在线观看| 国产叼嘿久久精品久久| 果冻传媒在线观看进入窗口| 九九久久久| 欧美肥婆性生活| 色婷婷AV99XX| 亚洲精品视频久久| 56prom在线精品国产| 俄罗斯9一14 young处|