Apache 2 hỗ trợ SSL/TLS: Hướng dẫn từng bước (Phần II)

Sau khi nhận lại chứng chỉ từ CA tin cậy, chúng ta phải chắc chắn rằng nó dang PEM chứ không phải là TXT hay DER. Nếu nhận được chứng chỉ không chuyển đổi từ bất kì định dạng nào nhận được sang dạng của PEM. Cách dễ nhất để kiểm tra định dạng của chứng chỉ là xem chứng chỉ bằng một Phụ thuộc vào trình soạn thảo nào mà chúng ta có một trong các định dạng sau chỉ ra trong ngoặc kép): - Định dạng PEM, Base64 encoded X.509 (*.crt, *.pem, *.cer)

pdf24 trang | Chia sẻ: lylyngoc | Ngày: 27/11/2013 | Lượt xem: 1877 | Lượt tải: 0download
Bạn đang xem nội dung tài liệu Apache 2 hỗ trợ SSL/TLS: Hướng dẫn từng bước (Phần II), để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
Apache 2 hỗ trợ SSL/TLS: Hướng dẫn từng bước (Phần II) Phần II Trong phần đầu tiên của loạt bài này, các bạn đã được hướng dẫn cách cài đặt, cấu h mềm Apache 2.0 hỗ trợ SSL/TLS. Bây giờ, phần hai sẽ tiếp tục thảo luận vấn đề thiết lập modul mod_ssl để đạt được mức an toàn cao nhất và sự thực thi tối ưu. Đồng thời các bạn cũng sẽ đ thế nào để tạo ra một Quyền hạn chứng chỉ (Certification Authority) nội bộ và m trên thư viện nguồn mở OpenSSL. Những yêu cầu thiết lập cho mod_ssl Trong Apache 2.0.52 có hơn 30 hướng dẫn có thể dùng để cấu hình mod_ssl. B hướng dẫn này có thể tìm thấy trong Apache's mod_ssl documentation. Phần n yêu cầu thiết lập để nâng cao độ an toàn và sự thực thi của kết nối SSL/TLS. Danh sách các thiết lập này được chỉ ra trong bảng dưới đây: Chỉ thị Các yêu cầu thiết lập hoặc chú thích SSLEngine Phải đặt ở chế độ cho phép, nếu không th trạm ảo) sẽ không dùng SSL/TLS được SSLRequireSSL Phải đặt ở chế độ cho phép, nếu không ng cập nội dung web qua các yêu cầu HTTP thông th không cần chút gì tới SSL/TLS. SSLProtocol SSLProxyProtocol Nên thiết lập chế độ chỉ dùng TLS v1.0 và SSL v3.0. H các web browser hiện nay đểu hỗ trợ cả hai. V thể vô hiệu hoá SSL v2.0 một cách an to SSLCipherSuite SSLProxyCipherSuite Để tạo ra phương thức mã hoá mạnh, tham số n HIGH (>168 bits) và MEDIUM (128 bits). M bits) và NULL (không mã hoá) đặt bộ m vô hiệu hoá. Nên vô hiệu hoá tất cả các bộ m dạng nặc danh (aNULL). Nhưng cũng tuỳ mục đích. Nếu chúng ta muốn hỗ trợ cho web browser mà không c dùng bộ mã hoá EXPORT (56 bit và 40 bit). chúng ta nên dùng SHA1 hơn là MD5. B an toàn hơn MD5, sau khi phát hiện ra các xung đột trong MD5. Tóm lại, các thiết lập cần thiết nên là: HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM Chú ý: có thể xem các thiết lập hỗ trợ bộ m openssl ciphers -v 'HIGH:MEDIUM:\!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM' SSLOptions Tuỳ chọn "+StrictRequire" nên được thiết lập, nếu không chỉ thị "Satisfy Any" có thể ép mod_ssl cho phép truy cập nội dung web ngay cả khi SSL/TLS không được d SSLRandomSeed Để khởi động Apache nên cài đặt để sử dụng thiết bị ngẫu nhi giả (/dev/urandom) và/hoặc EGD (Entrophy Gathering Daemon). Trước khi mỗi kết nối SSL mới đ cấu hình lại để dùng nguồn được cài đ EGD. Không nên dùng /dev/random trong c Bởi vì /dev/random chỉ có thể cung cấp nhiều entropy tại một thời điểm nhất định nào đó. SSLSessionCache Để tránh lặp lại các “bắt tay” SSL cho các y song (ví dụ khi web browser tải nhiều h khoảng thời gian), SSL caching nên đư để dùng bộ nhớ chia sẻ (SHM), hoặc DBM. Khi thiết lập n "none", thực thi của web server có thể giảm một cách đáng kể. SSLSessionCacheTimeout Giá trị này mô tả số giây thời gian sau k SSLSessionCache hết hiệu lực. Nó nên đư 600 giây. Tuy nhiên thời gian thực phụ thuộc v trung bình người dùng sử dụng trong mỗi lần viếng thăm web server. Ví dụ nếu thời gian trung bình là kho trị thiết lập nên ít nhất là 900 (15 phút * 60 giây). SSLVerifyClient SSLProxyVerify Khi không dùng bộ nhận dạng client hay proxy, các tuỳ chọn này nên đặt ở chế độ “none”. Không bao giờ n chế độ "optional_no_ca". Bởi vì ngược lại PKI, những chỗ nào client được nhận dạng, chúng phải đ các chứng chỉ phù hợp. “Optional” thỉnh thoảng đ thuộc xem là cần hay không), tuy nhiên nó có th việc với tất cả các web browser. SSLVerifyDepth SSLProxyVerifyDepth Nên là con số lớn nhất của CA trung gian. Ví dụ, để lấy chỉ các chứng chỉ tự kí nên đặt nó là 0, cho các ch bởi Root CA, nên đặt là 1… SSLProxyEngine Nên vô hiệu hoá (đặt ở chế độ disable), nếu c proxy không được dùng. Bảng 1. Các thiết lập cần thiết cho mod_ssl. Thiết lập mẫu của chúng ta tương ứng với các hướng dẫn trên có thể tìm thấy trong SSLEngine on SSLOptions +StrictRequire SSLRequireSSL SSLProtocol -all +TLSv1 +SSLv3 # Support only for strong cryptography SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM # Support for strong and export cryptography # SSLCipherSuite HIGH:MEDIUM:EXP:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM:+E SSLRandomSeed startup file:/dev/urandom 1024 SSLRandomSeed connect file:/dev/urandom 1024 SSLSessionCache shm:/usr/local/apache2/logs/ssl_cache_shm SSLSessionCacheTimeout 600 SSLVerify none SSLProxyEngine off Ngoài các hướng dẫn về mod_ssl ở trên còn có hai phần quan trọng khác trong Apache modules (mod_log_config và mod_set_envif) cũng cần được cài đặt theo bảng 2 sau đây: Chỉ thị Yêu cầu thiết lập hoặc chú thích CustomLog Để ghi thông tin về tham số của SSL (yêu cầu tối thiểu: phi của giao thức và bộ mã hoá được chọn) chúng ta n sau: CustomLog logs/ssl_request_log \ "%t %h %{HTTPS}x %{SSL_PROTOCOL}x %{SSL_CIPHER}x %{SSL_CIPHER_USEKEYSIZE}x %{SSL_CLIENT_VERIFY}x \"%r\" %b" Setenvif Để tương thích với các phiên bản cũ của MS Internet Explorer với các lỗi trong phần thực thi SSL (ví dụ các vấn đề với h alive, HTTP 1.1 trên SSL, các cảnh bào chú ý đóng SSL trên socket cuối kết nối. Các tuỳ chọn sau nên thiết lập: SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 Tuỳ chọn trên là nguyên nhân web server sẽ dùng HTTP/1.1 ho kết nối keep – alive và sẽ không gửi chú ý đóng SSL khi web browser là MS Internet Explorer. Bảng 2. Các yêu cầu thiết lập cho mod_log và mod_set_envif. File cấu hình mẫu (httpd.conf) thể hiện trong bài trước đã bao gồm các tuỳ chọn tr thuận tiện hơn. Bộ nhận dạng web server Cho tới giờ, chúng ta có thể cấu hình và kiểm tra SSL/TLS, nhưng web browser c kiểm tra được nhận dạng của web server. Trong bài đầu tiên, chúng ta đã dùng m được tạo ra nhằm mục đích kiểm tra và không chứa các thông tin yêu cầu cho nhận dạng thực v dịch thương mại. Để web browser nhận dạng thành công web server, chúng ta cần tạo ra một chứng chỉ web server ph hợp, nên bao gồm:  Khoá thông thường cho web server  Ngày tháng có hiệu lực (ngày bắt đầu và ngày hết hạn)  Hỗ trợ các thuật toán mã hoá  Bộ tên riêng biệt (DN), phải bao gồm đầy đủ tên miền có giá trị của web server, đ là tên thông thường (CN). Tuy nhiên cũng có thể có một số thành phần khác nh khu vực (L), tên tổ chức (O), tên đơn vị tổ chức (OU) hoặc có thể hơn.  Dãy số chứng chỉ  Thuộc tính X.509v3 sẽ nói cho web browser về kiểu và cách dùng của chứng chỉ  URI của điểm phân phối CRL (nếu tồn tại)  URI của X.509v3 Certificate Policy (nếu tồn tại)  Tên và chữ kí được xác nhận bởi bộ nhận dạng chứng chỉ (CA) Chú ý quan trọng là thuộc tính tên thông thường (CN) phải là tên miền có đủ điều kiện tr Nếu không web browser sẽ không thể kiểm chứng được chứng chỉ có thuộc web server đang d không. Mẫu chứng chỉ web server (mẫu kiểu text) có thể như sau: Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: O=Seccure, OU=Seccure Root CA Validity Not Before: Nov 28 01:00:20 2004 GMT Not After : Nov 28 01:00:20 2005 GMT Subject: O=Seccure, OU=Seccure Labs, CN=www.seccure.lab Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c1:19:c7:38:f4:89:91:27:a2:1b:1d:b6:8d:91: 48:63:0e:3d:0d:2e:f8:65:45:56:db:98:4d:11:21: 01:ac:81:8e:3f:64:4a:8a:3f:21:15:ca:49:6e:64: 5c:5d:a2:ab:5a:48:cb:2a:9f:0c:02:b9:ff:52:f6: d9:39:6d:a3:4a:94:41:f9:e9:ab:f0:42:fb:68:9a: 4b:53:41:e7:4f:b0:2b:02:d7:92:a2:2b:02:a2:f9: f1:2d:68:fa:50:01:2f:49:c1:28:2f:a8:c6:6d:6d: ab:1d:b9:bd:c9:80:63:f1:d6:22:19:de:2d:4a:43: 50:76:79:7e:a5:5a:75:af:19 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server X509v3 Key Usage: Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, Netscape Server Gated Crypto, Microsoft Server Gated Crypto Netscape Comment: OpenSSL Certificate for SSL Web Server Signature Algorithm: sha1WithRSAEncryption 45:30:9d:04:0e:b7:86:9e:61:a1:b0:68:2b:44:93:1c:57:2a: 99:42:bb:16:b1:ab:f5:c0:d2:33:12:c8:d3:1d:2b:bb:6b:9a: 4c:c7:53:bc:e4:88:ef:1e:c3:37:ed:53:2c:15:cf:b8:90:df: df:4b:34:b8:db:cc:23:77:46:06:72:9d:43:60:a8:a2:ed:0a: bb:1a:a4:e8:4e:ba:66:93:63:74:87:fd:43:48:b6:93:a2:e3: 3d:da:1b:64:46:35:88:b4:4b:22:e6:3c:84:70:5d:88:dd:64: c2:51:c2:d6:59:80:87:bc:bd:7f:e3:c1:45:7e:c0:5f:9c:ca: e1:a1 Ví dụ tiếp theo dựa trên một số giá trị thể hiện trong bảng 3. Để tạo ra một chứng chỉ đúng, các bạn cần thay thế một số giá trị này bằng tên công ty hay tổ chức của bạn: Mô tả thuộc tính Thuộc tính Ví dụ mẫu Mã quốc gia (2 kí tự) C C = PL Bang hay tỉnh S S = mazowieckie Khu vực L L = Warsaw Tên tổ chức O O = Seccure Đơn vị tổ chức OU OU = Seccure Labs Tên thông thường CN CN = www.seccure.lab Bảng 3. Ví dụ mẫu cho một chứng chỉ đúng Có nên dùng mật khẩu để bảo vệ? Trước khi bắt đầu tạo các chứng chỉ, việc hiểu ý nghĩa mật khẩu (passphrase) trong chứng chỉ l trọng. Các khoá private của web server có nên được mã hoá hay không? Có nhi trong đó có ý kiến cho rằng không nên bảo vệ khoá private bằng mật khẩu. Nó không chỉ bất tiện m tạo ra cảm giác thiếu an toàn. Vì sao? Hãy xem các điểm sau: 1. Thứ nhất, nó đòi hỏi phải nhập mật khẩu sau mỗi lần khởi động lại web server. Điều n nếu hệ thống cần khởi động lại thường xuyên (như do cập nhật lại code, một lỗi điện tử hay thay đổi cấu hình, v.v…). 2. Nếu một kẻ xâm nhập nào đó chế ngự và lấy đi khoá private trên web server, có ngh phá hoại và kẻ xâm nhập có quyền truy cập vào hệ điều hành của web server ở Root. Trong tr này, kẻ xâm nhập có thể lấy cắp mật khẩu bằng cách cài keylogger. Và sau đó, ho khởi động lại hệ thống để ép người quản trị nhập lại mật khẩu. Kẻ xâm nhập có thể kết xuất bộ nhớ của Apache và tìm ra khoá private của web server lưu trữ trong một đoạn nào đó. Do vậy, nâng cao mã hoá khoá private của web server bằng mật khẩu chỉ giúp bảo những đứa trẻ. Còn đối với các chuyên gia phá hoại hệ thống thì vô tác dụng. Tạo chứng chỉ web server Trong phần này chúng ta có thể tạo các chứng chỉ web server. Thông thường có 3 kiểu chứng chỉ m chúng ta có thể dùng: 1. Chứng chỉ tự kí (self-signed certificate) 2. Chứng chỉ được chứng nhận bởi CA (hầu hết) 3. Chứng chỉ được kí bởi CA nội bộ Phần dưới đây sẽ mô tả chi tiết phương thức tạo các chứng chỉ trên. Kết quả cuối c thức nào được dùng sẽ chỉ có 2 file:  server.key – khoá private của web server  server.crt - chứng chỉ mã hoá PEM bao gồm cả khoá public của web browser Phương thức 1: Chứng chỉ tự kí (chỉ dùng cho mục đích kiểm tra) Phương thức này được đưa ra chỉ để tiếp tục quá trình kiểm tra của chúng ta, ho nhỏ, gần gũi (chẳng hạn như tại nhà hay một mạng Intranets nhỏ). Để web browser có thể nhận dạng được web server chứng chỉ tự kí phải được cài đặt vào mọi web browser cần truy cập web server đó. Điều này có thể khá bất tiện. Cặp đôi khoá public/private của web server và chứng chỉ mã hoá tự kí PEM có thể đ openssl req \ -new \ -x509 \ -days 365 \ -sha1 \ -newkey rsa:1024 \ -nodes \ -keyout server.key \ -out server.crt \ -subj '/O=Seccure/OU=Seccure Labs/CN=www.seccure.lab' Các câu lệnh trên sẽ tạo ra một chứng chỉ mới (-new), có tên (-x509), có giá trị trong một năm ( 365), và sẽ được kí bằng cách dùng thuật toán SHA1 (-sha1). Khoá private RSA có đ newkey rsa: 10224), và không cần bảo vệ bằng mật khẩu (-nodes). Chứng chỉ v public/private sẽ được tạo trong hai file “server.crt” và “server.key”. Tên của khu vực n Labs” và tên miền đầy đủ là: www.seccure.lab. Sau khi tạo ra chứng chỉ trên, chúng ta cần phân phối và cài đặt nó trên mọi web browser có thể kết nối với web server. Nếu không thì khi web browser đòi hỏi một kết nối, nó sẽ không thể kiểm chứng đ nhận dạng của web server. Trong môi trường Windows, điều này được thể hiện trong h dưới đây: Phương thức 2: Chứng chỉ được kí bởi CA Tạo một yêu cầu chứng chỉ và kí nó bằng một CA tin cậy (chẳng hạn như Versign, Thawte, RSA,…) là cách được dùng nhiều nhất để biết web server SSL có được đưa vào internet hay không. Dùng cách ti cận này thì không cần phải cài đặt chứng chỉ tại mọi web browser. Bởi hầu hết chúng đ của chứng chỉ CA từ trước khi được cài đặt. Hãy chú ý rằng, mỗi một bộ thẩm định chứng chỉ (CA) có các giới hạn khác nhau trong việc phân phối tên riêng, cung cấp độ dài cho một khoá, các kí tự quốc tế. Do đó, trước khi tạo các y bạn cần chắc chắn rằng các yêu cầu chứng chỉ của bạn phù hợp với đòi hỏi cụ thể của CA. N CA mà các chứng chỉ đã kí của nó được cài đặt trên hầu hết các web browser (bao g và một số hãng khác…). Nếu không thì web browser của người dùng có thể gặp vấn đề kiểm định với web server. Quá trình thu được một chứng chỉ kí bởi một CA tin cậy bao gồm các bước sau: 1. Bước đầu tiên chúng ta nên tạo một cặp khoá public/private (trong server.key) và yêu c (trong request.pem) như sau: openssl req \ -new \ -sha1 \ -newkey rsa:1024 \ -nodes \ -keyout server.key \ -out request.pem \ -subj '/O=Seccure/OU=Seccure Labs/CN=www.seccure.lab' 2. Bây giờ chúng ta phải gửi yêu cầu chứng chỉ tới CA (trong request.pem). Sau đó ch nó được kí và gửi trả lại cho chúng ta form của chứng chỉ. 3. Sau khi nhận lại chứng chỉ từ CA tin cậy, chúng ta phải chắc chắn rằng nó đ dang PEM chứ không phải là TXT hay DER. Nếu nhận được chứng chỉ không m chuyển đổi từ bất kì định dạng nào nhận được sang dạng của PEM. Cách dễ nhất để kiểm tra định dạng của chứng chỉ là xem chứng chỉ bằng một tr Phụ thuộc vào trình soạn thảo nào mà chúng ta có một trong các định dạng sau (t chỉ ra trong ngoặc kép): - Định dạng PEM, Base64 encoded X.509 (*.crt, *.pem, *.cer) -----BEGIN CERTIFICATE----- MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj dXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN ... ou0Kuxqk6E66ZpNjdIf9Q0i2k6LjPdobZEY1iLRLIuY8hHBdiN1kwlHC1lmAh7y9 f+PBRX7AX5zK4aE= -----END CERTIFICATE----- - Định dạng TXT + PEM (*.crt, *.cer, *.pem, *.txt) Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: O=Seccure, OU=Seccure Root CA ... RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c1:19:c7:38:f4:89:91:27:a2:1b:1d:b6:8d:91: ... X509v3 extensions: X509v3 Basic Constraints: CA:FALSE ... -----BEGIN CERTIFICATE----- MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj dXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN ... ou0Kuxqk6E66ZpNjdIf9Q0i2k6LjPdobZEY1iLRLIuY8hHBdiN1kwlHC1lmAh7y9 f+PBRX7AX5zK4aE= -----END CERTIFICATE----- - Nếu chứng chỉ của bạn được nhận theo kiểu TXT + PEM, thì đây là câu lệnh để chuyển đổi nó sang dạng PEM: openssl x509 -in signed_cert.pem -out server.crt - DER, mã hoá binary encoded X.509 (*.der, *.crt, *.cer) [ non-text, binary representation ] - Nếu chứng chỉ của bạn nhận theo kiểu DER, thì câu lệnh chuyển đổi sang kiểu PEM l openssl x509 -in signed_cert.der -inform DER -out server.crt 4. Kiểm chứng và kiểm tra chứng chỉ Trước khi cài đặt chứng chỉ chúng ta nên kiểm tra xem liệu các chứng chỉ nhận đ và có thể dùng để thẩm định web server được chưa: openssl verify -CAfile /path/to/trusted_ca.crt -purpose sslserver server.crt Cũng như thế, nếu nó chạy tốt thì hãy chắc chắn rằng chứng chỉ có tương ứng với khoá private của web server được tạo trước đó hay không (kết quả của cả hai câu lệnh sau giống hệt nhau): openssl x509 -noout -modulus -in server.crt | openssl sha1 openssl rsa -noout -modulus -in server.key | openssl sha1

Các file đính kèm theo tài liệu này:

  • pdfbao_mat_17__4491.pdf
Luận văn liên quan