Apache HTTP 伺服器版本 2.4
Apache HTTP 伺服器版本 2.4
這章節的目的是作為一個簡介給了解 Web、HTTP 和 Apache 但並非安全專家的讀者。它並非打算成為 SSL 協定的必要指南，也不會討論在組織中管理憑證的具體技術，或有關專利和進出口限制的重要法律問題。相反地，它旨在透過彙集各種概念、定義和範例作為進一步探索的起點，提供 mod_ssl 使用者的共同背景知識。
了解 SSL 需要了解加密演算法、訊息摘要函數 (也稱為單向或雜湊函數) 和數位簽章。這些技術是完整書籍的主題 (例如 [AC96])，並提供隱私、完整性和驗證的基礎。
假設愛麗絲想要寄送訊息給她的銀行以匯款。愛麗絲希望訊息是私密的，因為它將包含她的帳戶號碼和匯款金額等資訊。一個解決方案是使用加密演算法，這是一種將她的訊息轉換為加密形式的技術，直到它被解密之前都無法閱讀。一旦格式化為這種形式，訊息只能使用密鑰進行解密。沒有密鑰，訊息就毫無用處：優良的加密演算法讓入侵者難以解碼原始文字，而這不值得他們花費力氣。
加密演算法有兩種：傳統和公開金鑰。
任何人都可以使用公開金鑰加密訊息，但只有私人金鑰的所有者可以讀取該訊息。透過這種方式，Alice 可以透過使用銀行的公開金鑰加密訊息來向擁有金鑰對的所有者（銀行）傳送私人訊息。只有銀行可以解密該訊息。
儘管 Alice 可能加密她的訊息以確保隱私，但仍會擔心有人修改她的原始訊息或以不同的訊息取代，例如將錢轉移到自己身上。Alice 確保其訊息完整性的一個方法是，讓她建立一個訊息的簡潔摘要，並將此發送到銀行。銀行收到訊息後，會建立自己的摘要，並與 Alice 所傳送的摘要進行比較。如果摘要相同，則表示訊息完整接收。
例如這樣的摘要稱為訊息摘要、單向函數或雜湊函數。訊息摘要用於建立較短、固定長度的摘要，來說明白長度不同的訊息。摘要演算法的設計目的，是為每則訊息產生獨特的摘要。訊息摘要的設計目的，是要讓透過摘要難以實際判斷訊息，而且（理論上）不可能找出兩個會產生相同摘要的不同訊息，從而消除了維持相同摘要時，用另一則訊息取代其中一則訊息的可能性。
Alice 面臨的另一個挑戰是，找出將摘要安全傳送至銀行的方法；如果摘要傳送不安全，其完整性可能會受到損害，銀行也因此難以判斷原始訊息的完整性。只有在摘要安全傳送的情況下，才能判斷相關訊息的完整性。
安全傳送摘要的方法之一，是將其包含在數位簽章中。
當 Alice 傳送訊息至銀行時，銀行需要確認訊息確實來自她，因此入侵者無法要求與其帳戶相關的交易。由 Alice 建立並與訊息一同傳送的數位簽章，具有此功能。
數位簽章是透過使用寄件者的私鑰，來加密訊息摘要和其他資訊（例如序列號碼）以建立的。雖然任何人都可以用公開金鑰來解密簽章，但只有寄件者知道私人金鑰。這表示只有寄件者能夠簽署訊息。在簽章中包含摘要，表示簽章僅適用於該則訊息；這也能確保訊息的完整性，因為沒有人可以變更摘要並簽署。
為了防止入侵者在後面截取並重複使用簽章，簽章包含一個獨特的序列號碼。這可保護銀行免於收到愛麗絲的欺詐性索賠，表示她沒有發送訊息，因為只有她才能簽署它（不可否認性）。
儘管愛麗絲可以向銀行傳送私人訊息、簽署訊息並確保訊息完整性，但她仍需要確定她真的與銀行保持溝通。這表示她需要確認她使用的公開金鑰是銀行金鑰對的一部分，而不是入侵者的。同樣地，銀行需要驗證訊息簽章確實是由屬於愛麗絲的私人金鑰簽署的。
如果每一方都有憑證，可以驗證對方的身分，確認公開金鑰並由可信賴的機構簽署，則雙方都能確定他們與他們所認為的人進行溝通。這種可信賴的機構稱為憑證授權中心 (CA)，而且憑證用於驗證。
憑證會將公開金鑰與個人、伺服器或其他實體的真實身分關聯，此實體稱為主體。如 表 1 所示，關於主體的資訊包括識別資訊（專有名稱）和公共金鑰。它還包括簽發憑證的憑證授權中心之識別和簽章，以及憑證有效的時段。憑證可能還有額外的資訊（或擴充）以及憑證授權中心使用的管理資訊，例如序號。
| 主體 | 專有名稱、公開金鑰 |
|---|---|
| 發行者 | 專有名稱、簽章 |
| 有效期間 | 起效日期、失效日期 |
| 管理資訊 | 版本、序號 |
| 擴充資訊 | 基本約束、Netscape 標記等 |
專有名稱用於在特定脈絡中提供身分，例如，個人可能有個人憑證和員工身分憑證。專有名稱由 X.509 標準 [X509] 所定義，此標準定義了用於參考欄位的名稱和縮寫（請參閱 表 2）。
| DN 欄位 | 縮寫 | 說明 | 範例 |
|---|---|---|---|
| 常用名稱 | CN | 需要認證的名稱 | CN=Joe Average |
| 組織或公司 | O | 名稱與下列 組織相關聯 |
O=Snake Oil, Ltd. |
| 組織單位 | OU | 名稱與下列 組織單位，例如部門 |
OU=Research Institute |
| 城市/地區 | L | 名稱位於下列城市 | L=Snake City |
| 州/省 | ST | 名稱位於下列州/省 | ST=Desert |
| 國家 | C | 名稱位於下列國家 (ISO 代碼) | C=XZ |
證書簽發機構可以定義政策，指定哪些識別欄位名稱為選用項目，以及哪些為必要項目。它也可以對欄位內容設下需求，證書使用者亦可如此。例如，Netscape 瀏覽器需要某伺服器證書的通用名稱，必須符合該伺服器網域名稱的萬用字元模式，例如 *.snakeoil.com。
證書的二進位格式是使用 ASN.1 表示法來定義的 [ASN1] [PKCS]。這個表示法會定義如何指定內容和編碼規則，定義這些資訊如何轉譯成二進位格式。證書的二進位編碼是使用 ASN.1 的 Distinguished Encoding Rules (DER) 來定義，它則是以 Basic Encoding Rules (BER) 為基礎。對於無法處理二進位的傳輸，可以用 Base 64 編碼將二進位格式轉換成 ASCII 格式 [MIME]。會在前後加上區隔行 (如下) 時，這個編碼版本稱為 PEM (「加強隱私郵件」) 編碼證書。
-----BEGIN CERTIFICATE----- MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt 2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7 dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ== -----END CERTIFICATE-----
證書簽發機構在提供證書前，會先驗證證書要求中的資訊，確認金鑰對的私有金鑰擁有者的身分。例如，如果 Alice 要求個人證書，證書簽發機構必須先確認 Alice 真的如證書要求所述的個人身分。
證書簽發機構也可以為另一個證書簽發機構簽發證書。Alice 在驗證證書時，可能需要驗證簽發者證書，並針對每個上層證書簽發機構執行此動作，直到達到她信賴的證書。她可以決定只信任有層級受限的簽發者才能開立的證書，以減少鏈中出現「不當」證書的風險。
正如先前所提，每個憑證都需要發行者確認憑證主體的身分有效性，直到最上層的憑證授權機構 (CA)。這產生了一個問題：誰能證明這最高層級機構的憑證？它沒有發行者。在這個獨特的情況中，憑證是「自我簽署」，因此，憑證的發行者與主體相同。瀏覽器預設信任知名的憑證授權機構，但對於信任自我簽署的憑證，必須特別小心。根憑證授權機構廣泛公開公開金鑰降低了信任此金鑰的風險，倘若其他人公告一組聲稱自己是憑證授權機構的金鑰，情況便會很明顯。
許多公司，例如 Thawte 和 VeriSign 建立了憑證授權機構。這些公司提供下列服務
你也可以建立自己的憑證授權機構。儘管在網際網路環境中風險很高，但在網際網路內部可能很實用，因為組織可以輕鬆驗證個人和伺服器的身分。
建立憑證授權機構是一項責任，需要穩固的管理、技術和管理架構。憑證授權機構不只會頒發憑證，還管理憑證，也就是決定憑證的有效期間、更新憑證並記錄過去頒發但現已過期的憑證清單（憑證吊銷清單或CRL）。
例如，如果 Alice 有資格取得身為公司員工的憑證，但現在已離開這家公司，她的憑證可能需要被吊銷。由於憑證只會在經過驗證主體身分後才會頒發，然後才會傳遞給所有與主體有所溝通的人，所以無法單從憑證中得知它已被吊銷。因此，在檢查憑證有效性時，有必要聯絡頒發憑證的憑證授權機構來檢查 CRL，而這通常不是自動程序的一部分。
如果你使用的憑證授權機構並非瀏覽器預設設定為信任，則必須將該憑證授權機構憑證載入瀏覽器中，讓瀏覽器能夠驗證由該憑證授權機構簽署的伺服器憑證。這麼做可能會很危險，因為載入後，瀏覽器就會接受所有由該憑證授權機構簽署的憑證。
安全通訊層通訊協定是一種通訊協定層，可以放置在可靠、面向連線的網路層協定（例如，TCP/IP）和應用程式協定層（例如，HTTP）之間。SSL 透過允許相互驗證、使用數位簽章確保完整性，以及使用加密確保隱私來提供客戶端和伺服器之間的安全通訊。
此協定設計是用於支援一系列用於密碼學、摘要和簽章之特定演算法的選項。這允許基於法律、出口或其他考量來針對特定伺服器選取演算法，而且也能讓此協定利用新的演算法。在建立協定會話時，由用戶端和伺服器協商選擇。
| 版本 | 來源 | 說明 |
|---|---|---|
| SSL v2.0 | 廠商標準（來自 Netscape Corp.） | 現有實作的第一份 SSL 協定 |
| SSL v3.0 | 過期的網路草案（來自 Netscape Corp.）[SSL3] | 修正，以防止特定的安全性攻擊，增加非 RSA 密碼，並支援憑證鏈 |
| TLS v1.0 | 建議的網路標準（來自 IETF）[TLS1] | SSL 3.0 的修正版本，以將 MAC 層更新為 HMAC，為區塊密碼新增區塊填補、訊息順序標準化和更多的警示訊息。 |
| TLS v1.1 | 建議的網路標準（來自 IETF）[TLS11] | TLS 1.0 的更新版本，用於針對 Cipher block chaining（CBC）攻擊新增防護。 |
| TLS v1.2 | 建議的網路標準（來自 IETF）[TLS12] | TLS 1.1 的更新版本，將 MD5 標記為不建議使用的雜湊函式，並新增與 SSL 的不相容性，因此永遠不會協商使用 SSLv2。 |
如 表格 4 所示，有許多 SSL 協定版本。如表中所述，SSL 3.0 的好處之一是它新增了憑證鏈載入的支援。此功能允許伺服器將伺服器憑證與發行者憑證一起傳遞給瀏覽器。即使中介發行者的憑證未安裝，鏈載入也允許瀏覽器驗證伺服器憑證，因為這些憑證包含在憑證鏈中。SSL 3.0 是傳輸層安全性 [TLS] 協定標準的基礎，目前正由網路工程工作小組 (IETF) 開發。
如 圖 1 所示，SSL 會話會遵循用戶端和伺服器之間的交握順序來建立。這個順序可能會有所不同，具體取決於伺服器是設定為提供伺服器憑證還是要求用戶端憑證。雖然在某些情況下，需要額外執行交握步驟才能管理密碼資訊，但這篇文章總結了一個常見的範例。請參閱 SSL 規範以了解所有可能的情況。
建立 SSL 會話之後，可以重複使用。這會避免執行啟動階段所需的許多步驟所產生的效能損失。為此，伺服器會為每個 SSL 會話指定一個唯一的會話識別碼，並將其快取在伺服器中，而且用戶端可以在未來的連線中使用它來減少交握時間（直到伺服器快取中的會話識別碼過期為止）。
圖 1：簡化的 SSL 交握順序
握手程序中由客戶端和伺服器使用的元素如下所列
第一個步驟「加密套件協商」允許客戶端和伺服器選擇兩者都支援的加密套件。SSL3.0 通訊協定規範定義了 31 個加密套件。加密套件由下列組成定義：
以下各節描述這三個元素。
金鑰交換方法定義將如何由客戶端和伺服器同意用於應用程式資料傳輸的共用秘密對稱加密金鑰。SSL 2.0 僅使用 RSA 金鑰交換，而 SSL 3.0 支援選擇金鑰交換演算法，包括 RSA 金鑰交換（在使用憑證時）和 Diffie-Hellman 金鑰交換（在不使用憑證交換金鑰時，或在客戶端與伺服器之間未事先通訊時）。
金鑰交換方法選擇中的一個變動因素是數位簽章 - 是否使用，如果使用，將使用哪種簽章。使用私密金鑰簽名，可防止在用於產生共用金鑰的資訊交換期間受到中間人攻擊 [AC96, p516]。
SSL 使用前面所述的傳統對稱加密，來加密通訊階段中的訊息。有九種加密方式可供選擇，包括不加密的選項
"CBC" 指的是密碼塊鏈接，意謂目前區塊的加密中使用了部分先前加密的密碼文字。"DES" 指的是資料加密標準 [AC96, ch12]，它有許多變體（包括 DES40 和 3DES_EDE）。"Idea" 目前是可用之中最強的密碼演算法，而 "RC2" 是 RSA DSI [AC96, ch13] 的專有演算法。
摘要函數的選擇決定了如何從記錄單位建立摘要。SSL 支援以下函數：
訊息摘要用於建立訊息驗證碼 (MAC)，此驗證碼會與訊息一同加密以驗證完整性並防止重播攻擊。
握手序列使用三個協定
這些協定及應用程式協定資料都封裝在 SSL 記錄協定 中，如 圖 2 所示。封裝的協定會由較低層協定作為資料傳輸，而不會檢查資料。封裝的協定不知道基礎協定。
圖 2：SSL 協定堆疊
控制協定的 SSL 封裝方式表示，如果對活躍的會話進行重新協商，控制協定會以安全的方式傳輸。如果沒有先前的會話，會使用 Null 加密套件，表示不會有加密，訊息也不會在會話建立之前具有完整性摘要。
圖 3 所示的 SSL 記錄協定用於在客戶端與伺服器之間傳輸應用程式和 SSL 控制資料，必要時會將這些資料切分成較小的單位，或將多個較高層級的協定資料訊息合併成單一單位。在透過基礎的可靠傳輸協定傳輸之前，它可能會壓縮、附加摘要簽章，並對這些單位進行加密（註：目前沒有主要 SSL 實作包含壓縮支援）。
圖 3：SSL 記錄協定
SSL 常見的用途之一是保護瀏覽器和網站伺服器之間的 Web HTTP 通訊。這不會排除使用未保護的 HTTP - 安全版本（稱為 HTTPS）與在 SSL 上的純粹 HTTP 相同，但使用 URL 結構 https 而非 http，以及不同的伺服器埠（預設為 443 埠）。此功能是 mod_ssl 為 Apache Web 伺服器提供的功能中，很大的一部分。
應用密碼學，第二版，Wiley，1996。請參閱 http://www.counterpane.com/ 取得 Bruce Schneier 提供的其他各種材料。
摘要語法標記法一 (ASN.1) 規格，上次更新於 2008 年。請參閱 http://www.itu.int/ITU-T/asn1/。
目錄 - 驗證架構。如需參考，請參閱 http://en.wikipedia.org/wiki/X.509。
公鑰加密標準 (PKCS)，RSA 實驗室技術說明，請參閱 http://www.rsasecurity.com/rsalabs/pkcs/。
多功能網際網路郵件擴充功能 (MIME) 第一部分：網際網路訊息主體格式，RFC2045。例如，請參閱 http://tools.ietf.org/html/rfc2045。
SSL 協定版本 3.0，1996 年。請參閱 http://www.netscape.com/eng/ssl3/draft302.txt。
TLS 協定版本 1.0，1999 年。請參閱 http://ietf.org/rfc/rfc2246.txt。
TLS 協定版本 1.1，2006 年。請參閱 http://tools.ietf.org/html/rfc4346。
TLS 協定版本 1.2，2008 年。請參閱 http://tools.ietf.org/html/rfc5246。
