加密方案發展一開始使用非對稱加密可以達到安全，但是效率太低，使用對稱秘鑰效率高，但如果寫入客戶端，被破解后就可以解密雙方數據，因為服務端也是相同的秘鑰服務端生成會話密鑰，進行非對稱加密下發，咋一看這個會話密鑰是加密后在網絡上傳輸的，但實際上里面存在一個問題：由于公鑰是公開的，因此任何人都能用公鑰解開并獲取你的會話密鑰。因此，這個方案也不夠完善。我們再回顧一下這個方案，發現存在一個本質的問題：這個會話密鑰是服務端單獨生成的，那一定會導致一種結果：只要客戶端能最終解密出來，那黑客也一定能解密出來。因為對于服務端而言，客戶端和黑客都是密鑰的接收方，兩者是平等的，無法區別的。客戶端主動生成密鑰具體方式如下：服務端明文下發公鑰給客戶端；客戶端生成一個隨機數作為會話密鑰，利用公鑰加密后發送給服務端；服務端收到后，通過私鑰對密文進行解密并獲取隨機數。可以看出這個過程里，黑客就算攔截了我們的加密數據，也會因為沒有私鑰而無法獲取會話密鑰。看起來，方案很完美了，但實際上里面仍然存在一個漏洞：如果最開始下發的明文公鑰就是假的呢？這會導致的結果是：用戶全程和一個中間黑客通信：信任黑客的公鑰，然后自以為安全的進行數據通信，結果把所有個人信息都暴露給黑客了，最重要的是，服務端對此一無所知！公鑰的合法性校驗為了公鑰的合法性校驗，人們建立了專門頒發證書的機構:“證書中心”（Certificateauthority，簡稱CA），它會利用自己的私鑰，將我們的公鑰和相關信息進行加密，生成一個數字證書。在客戶端內部，會存在一個受信任的根證書頒發機構，所以客戶端在每次拿到一個公鑰后，就去查詢這個公鑰是否在這里受信任證書列表中，如果不在，則認為公鑰無效，不再進行后續操作。如果存在，再繼續進行下一步認證。而這也和Https的實現機制相近。https原理前提非常重要的事情一加密方案中的加密算法都是公開的，而密鑰是保密的，沒有密鑰就不能解密，有了密鑰就能解密*三個角色客戶端代理服務器真實服務器所謂攔截破解攔截，就是代理服務器可以看到客戶端發給服務器的數據和服務端返回給客戶端的數據，并可以篡改指定信任證書https驗證流程，(還有不指定的，就是會默認用根證書驗證，但不能保證唯一性)用我們的證書去申請CA證書，一對CA公鑰和CA私鑰CA公鑰留在客戶端CA私鑰留在服務端建立鏈接握手過程中-》通過代理服務器-》到達服務端服務端返回-》代理服務器一個CA證書(用CA私鑰加密過的，只能CA公鑰去解，里面包含了我們自己的公鑰)，代理服務通過破解的App方式可以拿到證書(CA公鑰去解密證書，拿到里面的公鑰)通過公鑰加密自己生成對稱秘鑰反給服務器，服務器拿手里私鑰去解密，可以達到通信(但這并無意，我們自己也不知道和服務器通信做什么)這里可以達到冒充客戶端作用，應該沒意義吧代理服務器將CA證書給客戶端，客戶端通過使用本地CA證書公鑰解密，驗證通過，取出公鑰，生成對稱秘鑰，然后加密返回代理服務器，代理服務器拿到之后沒有私鑰，不能解密取出對稱秘鑰，只能返回給服務器對于瀏覽器客戶不留你們的證書，只有幾個最大的CA跟證書通過CA根證書驗證你們的CA證書，再通過CA證書驗證網站證書通過根證書驗證報CertificateException驗證失敗，就會彈出是否要信任此證書，同意可繼續瀏覽對于手機內置也有幾個最大的CA跟證書當我們App使用https時，通常會報CertificateException，表示該證書用手機根證書驗證失敗，因此我們解決辦法可能是信任所有證書，在客戶端中覆蓋google默認的證書檢查機制(X509TrustManager)，并且在代碼中無任何校驗SSL證書有效性相關代碼publicclassMySSLSocketFactoryextendsSSLSocketFactory{SSLContextsslContext=SSLContext.getInstance("TLS");publicMySSLSocketFactory(KeyStoretruststore)throwsNoSuchAlgorithmException,KeyManagementException,KeyStoreException,UnrecoverableKeyException{super(truststore);TrustManagertm=newX509TrustManager(){publicvoidcheckClientTrusted(X509Certificate[]chain,StringauthType)throwsCertificateException{}〃客戶端并未對SSL證書的有效性進行校驗，并且使用了自定義方法的方式覆蓋android自帶的校驗方法publicvoidcheckServerTrusted(X509Certificate[]chain,StringauthType)throwsCertificateException{}publicX509Certificate[]getAcceptedIssuers(){returnnull;}};sslContext.init(null,newTrustManager[]{tm},null);}}但問題出來了：如果用戶手機中安裝了一個惡意證書，那么就可以通過中間人攻擊的方式進行竊聽用戶通信以及修改request或者response中的數據。手機銀行中間人攻擊過程：客戶端在啟動時，傳輸數據之前需要客戶端與服務端之間進行一次握手，在握手過程中將確立雙方加密傳輸數據的密碼信息。中間人在此過程中將客戶端請求服務器的握手信息攔截后，模擬客戶端請求給服務器(將自己支持的一套加密規則發送給服務器)，服務器會從中選出一組加密算法與HASH算法，并將自己的身份信息以證書的形式發回給客戶端。證書里面包含了網站地址，加密公鑰，以及證書的頒發機構等信息。而此時中間人會攔截下服務端返回給客戶端的證書信息，并替換成自己的證書信息。客戶端得到中間人的response后，會選擇以中間人的證書進行加密數據傳輸。中間人在得到客戶端的請求數據后，以自己的證書進行解密。在經過竊聽或者是修改請求數據后，再模擬客戶端加密請求數據傳給服務端。就此完成整個中間人攻擊的過程。防護辦法：服務端使用CA機構頒發的證書，客戶端默認用根證書驗證就可以，(但只能驗證是否是合法的CA證書，只要是CA證書都能通過驗證，需要做訪問域名限制，(還是說默認CA頒發的就不敢做壞事，做壞事可以查))添加指定添加指定信任證書(這個證書可以是CA申請的(使用CA機構頒發證書的方式可行，但是如果與實際情況相結合來看的話，時間和成本太高，所以目前很少有用此辦法來做。)，也可以是自己自簽名生成的) 在客戶端內部，會存在一個受信任的根證書頒發機構，所以客戶端在每次拿到一個公鑰后，就去查詢這個公鑰是否在這里受信任證書列表中，如果不在，則認為公鑰無效，不再進行后續操作。如果存在，再繼續進行下一步認證。publicvoidinitSSL()throwsCertificateException,lOException,KeyStoreException,NoSuchAlgorithmException,KeyManagementException{CertificateFactorycf=CertificateFactory.getInstance("X.509");InputStreamin=getAssets().open("ca.crt");Certificateca=cf.generateCertificate(in);KeyStorekeystore=KeyStore.getInstance(KeyStore.getDefaultType());keystore.load(null,null);keystore.setCertificateEntry("ca",ca);StringtmfAlgorithm=TrustManagerFactory.getDefaultAlgorithm();TrustManagerFactorytmf=TrustManagerFactory.getInstance(tmfAlgorithm);tmf.init(keystore);//CreateanSSLContextthatusesourTrustManagerSSLContextcontext=SSLContext.getInstance("TLS");context.init(null,tmf.getTrustManagers(),null);URLurl=newURL("/CAtest/");// URLurl=newURL("");HttpsURLConnectionurlConnection=(HttpsURLConnection)url.openConnection();urlConnection.setSSLSocketFactory(context.getSocketFactory());InputStreaminput=urlConnection.getInputStream();BufferedReaderreader=newBufferedReader(newInputStreamReader(input,"UTF-8"));StringBufferresult=newStringBuffer();Stringline="";while((line=reader.readLine())!=null){result.append(line);}Log.e("TTTT",result.toString());? 由于手機銀行服務器其實是固定的，所以證書也是固定的，可以使用“證書或公鑰鎖定”的辦法來防護證書有效性未作驗證的問題。這相當不用默認根證書去校驗，而是自己去校驗publicfinalclassPubKeyManagerimplementsX509TrustManager{privatestaticStringPUB_KEY="30820122300d06092a864886f70d0101"+ -”0105000382010f003082010a0282010100b35ea8adaf4cb6db86068a836f3c85”+"5a545b1f0cc8afb19e38213bac4d55c3f2f19df6dee82ead67f70a990131b6bc"+"ac1a9116acc883862f00593199df19ce027c8eaaae8e3121f7f329219464e657"+"2cbf66e8e229eac2992dd795c4f23df0fe72b6ceef457eba0b9029619e0395b8"+"609851849dd6214589a2ceba4f7a7dcceb7ab2a6b60c27c69317bd7ab2135f50"+"c6317e5dbfb9d1e55936e4109b7b911450c746fe0d5d07165b6b23ada7700b00"+"33238c858ad179a82459c4718019c111b4ef7be53e5972e06ca68a112406da38"+"cf60d2f4fda4d1cd52f1da9fd6104d91a34455cd7b328b02525320a35253147b"+"e0b7a5bc860966dc84f10d723ce7eed5430203010001”;〃鎖定證書公鑰在apk中publicvoidcheckServerTrusted(X509Certificate[]chain,StringauthType)throwsCertificateException{if(chain==null){thrownewIllegalArgumentException("checkServerTrusted:X509Certificatearrayisnull”);}if(!(chain.length>0)){thrownewIllegalArgumentException("checkServerTrusted:X509Certificateisempty");}if(!((null!=authType)&&authType.equalsIgnoreCase("RSA"))){thrownewCertificateException("checkServerTrusted:AuthTypeisnotRSA");}//PerformcustomarySSL/TLScheckstry{TrustManagerFactorytmf=TrustManagerFactory.getInstance("X509”);tmf.init((KeyStore)null);for(TrustManagertrustManager:tmf.getTrustManagers()){((X509TrustManager)trustManager).checkServerTrusted(chain,authType);}}catch(Exceptione){thrownewCertificateException(e);}//Hackahead:BigIntegerandtoString().WeknowaDERencodedPublicKeybegins//with0?30(ASN.1SEQUENCEandCONSTRUCTED),sothereisnoleading0?00todrop.RSAPublicKeypubkey=(RSAPublicKey)chain[0].getPublicKey();Stringencoded=newBigInteger(1/*positive*/,pubkey.getEncoded()).toString(16);//Pinit!finalbooleanexpected=PUB_KEY.equalsIgnoreCase(encoded);if(!expected){thrownewCertificateException("checkServerTrusted:Expectedpublickey:"+PUB_KEY+",gotpublickey:"+encoded);}}}上面方法都可避免中間攻擊人冒充服務端，因為中間攻擊人不能串改服務端證書，只能用和服務端相同的證書，即使證書我們可以通過服務端下發拿到，但是沒有私鑰也解密不了信息以上如果以上還是存在一個問題，就是中間攻擊人可以冒充客戶端，使用根證書公鑰進行解密獲得公鑰等信息，驗證服務器數據簽名，然后加密自己對稱秘鑰發給服務器，達到偽裝客戶端目的為了客戶端不被冒充使用Https雙向驗證，在客戶端也保留個證書，發給服務端驗證，但是如果客戶端被破解取得證書也會被冒充publicclassSSLHelper{privatestaticfinalStringKEY_STORE_TYPE_BKS="bks";privatestaticfinalStringKEY_STORE_TYPE_P12="PKCS12publicstaticfinalStringKEY_STORE_CLIENT_PATH="server.pfx”;//P12文件privatestaticfinalStringKEY_STORE_TRUST_PATH="client.truststore”;//truststore文件publicstaticfinalStringKEY_STORE_PASSWORD="123456";//P12文件密碼privatestaticfinalStringKEY_STORE_TRUST_PASSWORD="123456”;//truststore文件密碼publicstaticSSLSocketFactorygetSSLSocketFactory(Contextcontext){SSLSocketFactoryfactory=null;try{//服務器端需要驗證的客戶端證書KeyStorekeyStore=KeyStore.getInstance(KEY_STORE_TYPE_P12);-- //客戶端信任的服務器端證書KeyStoretrustStore=KeyStore.getInstance(KEY_STORE_TYPE_BKS); 一InputStreamksIn=context.getResources().getAssets().open(KEY_STORE_CLIENT_PATH);InputStreamtsIn=context.getResources().getAssets().open(KEY_STORE_TRUST_PATH);try{keyStore.load(ksIn,KEY_STORE_PASSWORD.toCharArray());trustStore.load(tsIn,KEY_STORE_TRUST_PASSWORD.toCharArray());}catch(Exceptione){e.printStackTrace();}finally{try{ksIn.close();}catch(Exceptione){e.printStackTrace();}try{tsIn.close();}catch(Exceptione){e.printStackTrace();}}〃信任管理器TrustManagerFactorytrustManagerFactory=TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());trustManagerFact