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)
24 trang |
Chia sẻ: lylyngoc | Lượt xem: 3060 | Lượt tải: 0
Bạn đang xem trước 20 trang tài liệu Apache 2 hỗ trợ SSL/TLS: Hướng dẫn từng bước (Phần II), để xem tài liệu hoàn chỉnh 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:
- bao_mat_17__4491.pdf