瞭解用於從Android使用.Net webservice的SSL

Question

我正在開發一個Android應用程序，它需要通過SSL使用.Net Web服務，我沒有經驗。現在我正在尋找一些關於SSL握手和證書的指導和解釋。

注意：服務器正在使用IP地址和NOT域名。它是一個Intranet應用程序。

到目前爲止，我已經創造了Web服務器證書（？所謂的自簽發）從IIS 7 從Android應用程序使用它，我發現這樣做的方法有兩種：

1）。在證書中嵌入證書（哪個證書？我如何得到它？）

2）。相信所有證書（PPL說有安全問題，通過這種方法，你可以闡述多個是否仍然這樣做握手？）

證書：

如何證書的許多類型是有在握手中，他們是什麼？

自簽名證書是否具有根證書？如果是的話，我怎樣才能得到它們？

是否可以移動/從一臺服務器複製自簽名證書到另一個？

握手：

首先，是這個過程是否正確？通過發送一個URL 開始與下列

1. 客戶機啓動SSL握手過程：https：//開頭到服務器

   的SSL握手過程（從網站複製）進行說明。

2. 客戶端最初向Web服務器發送它支持的每種加密算法列表。 SSL支持的算法包括RC4 和數據加密標準（DES）。客戶端還向服務器 發送隨機挑戰字符串，該字符串稍後將在 進程中使用。

   嵌入式證書是否會在這裏發送？

3. Web服務器接下來將執行以下任務：

   從加密算法 所支持的列表中選擇加密算法，並從客戶端接收。

   向客戶端發送其服務器證書的副本。

   向客戶端發送的隨機挑戰字符串

4. 客戶端利用從 收到的服務器進行身份驗證服務器的身份的服務器證書的複印件。

5. 客戶端從服務器 證書中獲取服務器的公鑰。

6. 客戶端接下來生成預主密鑰。這是一個不同的 隨機字符串，該字符串隨後將被用於生成SSL會話的會話密鑰 。然後，客戶端使用服務器的公鑰對名爲premaster secret的不同值 進行加密， 將此加密值返回給服務器。這伴隨着 握手消息的密鑰散列和主密鑰。散列 用於保護握手過程中交換的消息。 散列是從服務器和客戶端之間傳輸的前兩個隨機字符串 生成的。

   什麼是主密鑰？

7. 服務器發送客戶端到目前爲止在雙方之間交換的所有握手信息的密鑰散列。

   這是由什麼做的密鑰散列？

8. 的服務器，然後在客戶端生成從 不同的隨機值和鍵的會話密鑰，並通過應用一個數學計算 。

9. 會話密鑰用作共享密鑰來加密和解密在服務器和客戶端之間交換的數據。

會話密鑰在SSL會話超時或終止時被丟棄。

Answer 1

我會盡力回答最好在這裏我所知

• 的嵌入式應用中的證書（證書？如何獲得它？） 此證書識別客戶的/應用程序標識。您可以通過CA或自簽名獲取。此證書將被服務器用來驗證客戶端/應用的身份

• 信任所有證書（PPL表示，目前使用這種方法的安全性問題，你能不能詳細闡述更多？它是否仍然這樣做握手？） 它仍然握手，但它不會執行證書驗證，除非您內部連接（看起來您是），否則這是非常危險的。信任所有證書意味着實體可以聲稱自己不是某個人，從而可以從用戶那裏獲得機密信息。

• 握手中有多少種證書類型，它們是什麼？在握手過程中，您擁有服務器證書和客戶證書（用於雙因素身份驗證）

• 自簽名證書是否具有根證書？如果是的話，我怎樣才能得到它們？根據我所知，根證書是指由CA本身標識的證書，因此它沒有其他簽名。由於您的身份仍然可以驗證並需要由CA簽名，因此您不會被歸類爲根證書

• 是否可以將自簽名證書從一臺服務器移動/複製到另一臺？雖然從一個平臺到另一個平臺的過程是不同的，但簡短答案是肯定的。檢查[此鏈接]（http://www.sslshopper.com/how-to-move-or-copy-an-ssl-certificate-from-one-server-to-another.html），它有指示要複製少數平臺證書

• 嵌入式證書是否會在這裏發送？不，在驗證服務器的身份驗證完成後發送嵌入式（客戶端）證書

• 什麼是主密鑰？主密鑰是用於派生會話密鑰以供稍後進行通信的密鑰。它也被用來散列消息並在下一組階段中驗證消息的真實性。

• 什麼是由此產生的密鑰散列？它由客戶端發送的主密鑰製成。爲了驗證所有消息，服務器發送了所有已通過並使用主密鑰散列的消息。客戶端也會用相同的密鑰散列它的消息，然後與服務器發送的數據進行比較。只有當哈希值匹配，然後我們可以肯定，我們仍然使用相同的服務器