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

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 vdịch thương mại.. Để web browser nhận dạng thành công we

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:

SSLProtocol

SSLProxyProtocol

Nên thiết lập chế độ chỉ dùng TLS v1.0 và SSL v3.0 Hcá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ố nHIGH (>168 bits) và MEDIUM (128 bits) Mbits) 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ộ mdạ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 cdù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

cấu hình lại để dùng nguồn được cài đEGD Không nên dùng /dev/random trong cBở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 ysong (ví dụ khi web browser tải nhiều hkhoả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ể

trị thiết lập nên ít nhất là 900 (15 phút * 60 giây)

thuộc xem là cần hay không), tuy nhiên nó có thviệc với tất cả các web browser

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

SSLRandomSeed startup file:/dev/urandom 1024

SSLRandomSeed connect file:/dev/urandom 1024

Tuỳ chọn trên là nguyên nhân web server sẽ dùng HTTP/1.1 hokết nối keep – alive và sẽ không gửi chú ý đóng SSL khi web browser là MS Internet Explorer

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 vdị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 phhợ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 dkhô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)

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:

Thuộc tính

Ví dụ mẫu

Mã quốc gia (2 kí tự)

Khu vực L L = Warsaw

Đơn vị tổ chức

Tên thông thường

CN

CN

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ỉ ltrọ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 mtạ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ỉ mchú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ể đ

-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 ticậ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:

-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 -

MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNjdXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN

Signature Algorithm: sha1WithRSAEncryption

Issuer: O=Seccure, OU=Seccure Root CA

RSA Public Key: (1024 bit)

Modulus (1024 bit):

- 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