Tài liệu Apache 2 hỗ trợ SSL/TLS: Hướng dẫn từng bước (Phần II) potx

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

<Directory />
SSLRequireSSL
</Directory>

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 kh
oá 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
MIICdzCCAeCgAwIBAgIBATANBgk
qhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj
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