tìm hiểu thêm về ssl

Tìm hiểu về SSL
(Thứ Hai, 06/08/2007 - 9:44 AM)
Bài viết sẽ trình bày những yếu tố mà SSL đã kết hợp để thiết lập được một giao dịch an toàn
nhằm bảo vệ những thông tin mật trên mạng Internet hay bất kỳ mạng
TCP/IP nào.
1.SSL là gì?
Việc kết nối giữa một Web browser tới bất kỳ điểm nào trên mạng Internet đi
qua rất nhiều các hệ thống độc lập mà không có bất kỳ sự bảo vệ nào với các thông tin trên
đường truyền. Không một ai kể cả người sử dụng lẫn Web server có bất kỳ sự kiểm soát nào đối
với đường đi của dữ liệu hay có thể kiểm soát được liệu có ai đó thâm nhập vào thông tin trên
đường truyền. Để bảo vệ những thông tin mật trên mạng Internet hay bất kỳ mạng TCP/IP nào,
SSL đã kết hợp những yếu tố sau để thiết lập được một giao dịch an toàn:
• Xác thực: đảm bảo tính xác thực của trang mà bạn sẽ làm việc ở đầu kia của kết nối.
Cũng như vậy, các trang Web cũng cần phải kiểm tra tính xác thực của người sử dụng.
• Mã hoá: đảm bảo thông tin không thể bị truy cập bởi đối tượng thứ ba. Để loại trừ việc
nghe trộm những thông tin “ nhạy cảm” khi nó được truyền qua Internet, dữ liệu phải
được mã hoá để không thể bị đọc được bởi những người khác ngoài người gửi và người
nhận.
• Toàn vẹn dữ liệu: đảm bảo thông tin không bị sai lệch và nó phải thể hiện chính xác
thông tin gốc gửi đến.
Với việc sử dụng SSL, các Web site có thể cung cấp khả năng bảo mật thông tin, xác thực và
toàn vẹn dữ liệu đến người dùng. SSL được tích hợp sẵn vào các browser và Web server, cho
phép người sử dụng làm việc với các trang Web ở chế độ an toàn. Khi Web browser sử dụng kết
nối SSL tới server, biểu tượng ổ khóa sẽ xuất hiện trên thanh trạng thái của cửa sổ browser và
dòng “http” trong hộp nhập địa chỉ URL sẽ đổi thành “https”. Một phiên giao dịch HTTPS sử
dụng cổng 443 thay vì sử dụng cổng 80 như dùng cho HTTP.
2.Giao thức SSL
Được phát triển bởi Netscape, ngày nay giao thức Secure Socket Layer (SSL) đã được sử dụng
rộng rãi trên World Wide Web trong việc xác thực và mã hoá thông tin giữa client và server. Tổ
chức IETF (Internet Engineering Task Force ) đã chuẩn hoá SSL và đặt lại tên là TLS (Transport
Layer Security). Mặc dù là có sự thay đổi về tên nhưng TSL chỉ là một phiên bản mới của SSL.

Phiên bản TSL 1.0 tương đương với phiên bản SSL 3.1. Tuy nhiên SSL là thuật ngữ được sử
dụng rộng rãi hơn.
SSL được thiết kế như là một giao thức riêng cho vấn đề bảo mật có thể hỗ trợ cho rất nhiều ứng
dụng. Giao thức SSL hoạt động bên trên TCP/IP và bên dưới các giao thức ứng dụng tầng cao
hơn như là HTTP (Hyper Text Transport Protocol), IMAP ( Internet Messaging Access Protocol)
và FTP (File Transport Protocol). Trong khi SSL có thể sử dụng để hỗ trợ các giao dịch an toàn
cho rất nhiều ứng dụng khác nhau trên Internet, thì hiện nay SSL được sử dụng chính cho các
giao dịch trên Web.
SSL không phải là một giao thức đơn lẻ, mà là một tập các thủ tục đã được chuẩn hoá để thực
hiện các nhiệm vụ bảo mật sau:
• Xác thực server: Cho phép người sử dụng xác thực được server muốn kết nối. Lúc này,
phía browser sử dụng các kỹ thuật mã hoá công khai để chắc chắn rằng certificate và
public ID của server là có giá trị và được cấp phát bởi một CA (certificate authority)
trong danh sách các CA đáng tin cậy của client. Điều này rất quan trọng đối với người
dùng. Ví dụ như khi gửi mã số credit card qua mạng thì người dùng thực sự muốn kiểm
tra liệu server sẽ nhận thông tin này có đúng là server mà họ định gửi đến không.
• Xác thực Client: Cho phép phía server xác thực được người sử dụng muốn kết nối. Phía
server cũng sử dụng các kỹ thuật mã hoá công khai để kiểm tra xem certificate và public
ID của server có giá trị hay không và được cấp phát bởi một CA (certificate authority)
trong danh sách các CA đáng tin cậy của server không. Điều này rất quan trọng đối với
các nhà cung cấp. Ví dụ như khi một ngân hàng định gửi các thông tin tài chính mang
tính bảo mật tới khách hàng thì họ rất muốn kiểm tra định danh của người nhận.
• Mã hoá kết nối: Tất cả các thông tin trao đổi giữa client và server được mã hoá trên
đường truyền nhằm nâng cao khả năng bảo mật. Điều này rất quan trọng đối với cả hai
bên khi có các giao dịch mang tính riêng tư. Ngoài ra, tất cả các dữ liệu được gửi đi trên
một kết nối SSL đã được mã hoá còn được bảo vệ nhờ cơ chế tự động phát hiện các xáo
trộn, thay đổi trong dữ liệu. ( đó là các thuật toán băm – hash algorithm).
Giao thức SSL bao gồm 2 giao thức con: giao thức SSL record và giao thức SSL handshake.
Giao thức SSL record xác định các định dạng dùng để truyền dữ liệu. Giao thức SSL handshake
(gọi là giao thức bắt tay) sẽ sử dụng SSL record protocol để trao đổi một số thông tin giữa server

và client vào lấn đầu tiên thiết lập kết nối SSL.
3.Các thuật toán mã hoá dùng trong SSL
Các thuật toán mã hoá (cryptographic algorithm hay còn gọi là cipher) là các hàm toán học được
sử dụng để mã hoá và giải mã thông tin. Giao thức SSL hỗ trợ rất nhiều các thuật toán mã hoá,
được sử dụng để thực hiện các công việc trong quá trình xác thực server và client, truyền tải các
certificates và thiết lập các khoá của từng phiên giao dịch (sesion key). Client và server có thể hỗ
trợ các bộ mật mã (cipher suite) khác nhau tuỳ thuộc vào nhiều yếu tố như phiên bản SSL đang
dùng, chính sách của công ty về độ dài khoá mà họ cảm thấy chấp nhận được - điều này liên
quan đến mức độ bảo mật của thông tin, ….
Các bộ mật mã được trình bày ở phần sau sẽ đề cập đến các thuật toán sau:
• DES (Data Encryption Standard) là một thuật toán mã hoá có chiều dài khoá là 56 bit.
• 3-DES (Triple-DES): là thuật toán mã hoá có độ dài khoá gấp 3 lần độ dài khoá trong mã
hoá DES
• DSA (Digital Signature Algorithm): là một phần trong chuẩn về xác thực số đang được
được chính phủ Mỹ sử dụng.
• KEA (Key Exchange Algorithm) là một thuật toán trao đổi khoá đang được chính phủ
Mỹ sử dụng.
• MD5 (Message Digest algorithm) được phát thiển bởi Rivest.
• RSA: là thuật toán mã hoá công khai dùng cho cả quá trình xác thực và mã hoá dữ liệu
được Rivest, Shamir, and Adleman phát triển.
• RSA key exchange: là thuật toán trao đổi khoá dùng trong SSL dựa trên thuật toán RSA.
• RC2 and RC4: là các thuật toán mã hoá được phát triển bởi Rivest dùng cho RSA Data
Security.
• SHA-1 (Secure Hash Algorithm): là một thuật toán băm đang được chính phủ Mỹ sử
dụng.
Các thuật toán trao đổi khoá như KEA, RSA key exchange được sử dụng để 2 bên client và
server xác lập khoá đối xứng mà họ sẽ sử dụng trong suốt phiên giao dịch SSL. Và thuật toán
được sử dụng phổ biến là RSA key exchange.
Các phiên bản SSL 2.0 và SSL 3.0 hỗ trợ cho hầu hết các bộ mã hoá. Người quản trị có thể tuỳ
chọn bộ mã hoá sẽ dùng cho cả client và server. Khi một client và server trao đổi thông tin trong

giai đoạn bắt tay (handshake), họ sẽ xác định bộ mã hoá mạnh nhất có thể và sử dụng chúng
trong phiên giao dịch SSL.
4.Các bộ mã hoá sử dụng thuật toán trao đổi khoá RSA
Đây là danh sách các bộ mã hoá được hỗ trợ trong SSL mà sử dụng thuật toán trao đổi khoá RSA
và được liệt kê theo khả năng bảo mật từ mạnh đến yếu.
Mạnh nhất
• Thuật toán mã hoá 3- DES, thuật toán xác thực SHA-1
Mạnh
• Thuật toán mã hoá RC4 (với độ dài khoá 128 bit), thuật toán xác thực MD5
• Thuật toán mã hoá RC2 (với độ dài khoá 128 bit), thuật toán xác thực MD5
• Thuật toán mã hoá DES (với độ dài khoá 56 bit), thuật toán xác thực SHA –1
Tương đối mạnh
• Thuật toán mã hoá RC4 (với độ dài khoá 40 bit), thuật toán xác thực MD5
• Thuật toán mã hoá RC2 (với độ dài khoá 40 bit), thuật toán xác thực MD5
Yếu nhất
• Không mã hoá thông tin, chi dùng thuật toán xác thực MD5
Chú ý:Khi nói các thuật toán mã hoá RC4 và RC2 có độ dài khoá mã hoá là 40 bit thì thực chất
độ dài khoá vẫn là 128 bit nhưng chỉ có 40 bit được dùng để mã hoá.
5.SSL handshake
Giao thức SSL sử dụng kết hợp 2 loại mã hoá đối xứng và công khai. Sử dụng mã hoá đối xứng
nhanh hơn rất nhiều so với mã hoá công khai khi truyền dữ liệu, nhưng mã hoá công khai lại là
giải pháp tốt nhất trong qúa trình xác thực. Một giao dịch SSL thường bắt đầu bởi quá trình “bắt
tay” giữa hai bên (SSL handshake). Các bước trong quá trình “bắt tay” có thể tóm tắt như sau:
1. Client sẽ gửi cho server số phiên bản SSL đang dùng, các tham số của thuật toán mã hoá,
dữ liệu được tạo ra ngẫu nhiên (đó chính là digital signature) và một số thông tin khác mà
server cần để thiết lập kết nối với client.
2. Server gửi cho client số phiên bản SSL đang dùng, các tham số của thuật toán mã hoá, dữ
liệu được tạo ra ngẫu nhiên và một số thông tin khác mà client cần để thiết lập kết nối với
server. Ngoài ra server cũng gửi certificate của nó đến client, và yêu cầu certificate của
client nếu cần.

3. Client sử dụng một số thông tin mà server gửi đến để xác thực server. Nếu như server
không được xác thực thì người sử dụng sẽ được cảnh báo và kết nối không được thiết lập.
Còn nếu như xác thực được server thì phía client sẽ thực hiện tiếp bước 4.
4. Sử dụng tất cả các thông tin được tạo ra trong giai đoạn bắt tay ở trên, client (cùng với sự
cộng tác của server và phụ thuộc vào thuật toán được sử dụng) sẽ tạo ra premaster secret
cho phiên làm việc, mã hoá bằng khoá công khai (public key) mà server gửi đến trong
certificate ở bước 2, và gửi đến server.
5. Nếu server có yêu cầu xác thực client, thì phía client sẽ đánh dấu vào phần thông tin riêng
chỉ liên quan đến quá trình “bắt tay” này mà hai bên đều biết. Trong trường hợp này,
client sẽ gửi cả thông tin được đánh dấu và certificate của mình cùng với premaster secret
đã được mã hoá tới server.
6. Server sẽ xác thực client. Trường hợp client không được xác thực, phiên làm việc sẽ bị
ngắt. Còn nếu client được xác thực thành công, server sẽ sử dụng khoá bí mật (private
key) để giải mã premaster secret, sau đó thực hiện một số bước để tạo ra master secret.
7. Client và server sẽ sử dụng master secret để tạo ra các session key, đó chính là các khoá
đối xứng được sử dụng để mã hoá và giải mã các thông tin trong phiên làm việc và kiểm
tra tính toàn vẹn dữ liệu.
8. Client sẽ gửi một lời nhắn đến server thông báo rằng các message tiếp theo sẽ được mã
hoá bằng session key. Sau đó nó gửi một lời nhắn đã được mã hoá để thông báo rằng phía
client đã kết thúc giai đoạn “bắt tay”.
9. Server cũng gửi một lời nhắn đến client thông báo rằng các message tiếp theo sẽ được mã
hoá bằng session key. Sau đó nó gửi một lời nhắn đã được mã hoá để thông báo rằng
server đã kết thúc giai đoạn “bắt tay”.
10. Lúc này giai đoạn “bắt tay” đã hoàn thành, và phiên làm việc SSL bắt đầu. Cả hai phía
client và server sẽ sử dụng các session key để mã hoá và giải mã thông tin trao đổi giữa
hai bên, và kiểm tra tính toàn vẹn dữ liệu
PHẦN I: Tổng quát
Trong hơn mười năm, giao thức SSL đã được sử dụng rộng rãi nhằm vào mục đích đảm bảo an
toàn cho các giao dịch web qua internet. Bạn có thể tưởng tượng mỗi ngày có hàng triệu, hàng tỉ
đô la giao dịch trên mạng dùng SSL. Tuy nhiên, sự thật giản dị là chúng ta đã dùng SSL một

cách không thực sự cần thiết. Các thông tin được gửi qua giao thức này vẫn đảm bảo an toàn.
Cách mã hoá yếu, không kiểm chứng được các certificate (chứng chỉ) của web servers (trên máy
chủ), những lỗ hổng an ninh, cùng nhiều kiểu tấn công khác có thể cho phép những kẻ xâm nhập
truy cập thông tin nhạy cảm, bất chấp sự thật rằng nó đang được gửi qua SSL.
Bài báo này bắt đầu cho loạt bài giới thiệu về cấu hình của Apache 2.0 có hỗ trợ giao thức
SSL/TLS, nhằm bảo đảm an ninh tối đa và sự thực thi tối ưu trong hoạt động truyền tải của SSL.
- Phần I: Giới thiệu về các khía cạnh của khoá (key) trong SSL/TLS và hướng dẫn cách cài đặt,
thiết lập cấu hình của 2.0 có hỗ trợ các giao thức này.
- Phần II: Thảo luận về cấu hình của mod_ssl và các nguồn cung cấp địa chỉ với bộ xác nhận
web server.
- Phần III (cũng là phần cuối cùng): Thảo luận các vấn đề về xác định quyền máy khách (client)
và một số lỗi cấu hình điển hình của các nhà quản trị. Các lỗi này có thể giảm mức an toàn của
bất kì mạng truyền thông sử dụng SSL nào.
Giới thiệu về SSL
Secure Sockets Layer (SSL) là giao thức được biết đến nhiều nhất về khả năng bảo mật và độ
tin cậy trong giao dịch khách - chủ (client-server) trên mạng internet. Bản thân SSL được dựa
trên các khái niệm khá đơn giản. Nó sắp xếp các thuật toán mã hoá và khoá giữa 2 lần gửi - nhận
của một giao dịch. Sau đó thiết lập một đưòng dẫn ảo mã hoá thông qua các giao thức khác (như
HTTP). SSL cũng có thể thẩm định cả hai chiều của giao dịch thông qua việc dùng các “chứng
chỉ” (certificate).
SSL là giao thức tầng (layered protocol), bao gồm 4 giao thức con sau:
• Giao thức SSL Handshake
• Giao thức SSL Change Cipher Spec
• Giao thức SSL Alert
• SSL Record Layer
Vị trí của các giao thức trên, tương ứng với mô hình TCP/IP được minh hoạ theo biểu đồ sau:
Biểu đồ 1. Các giao thức con của SSL trong mô hình TCP/IP
Theo biểu đồ trên, SSL nằm trong tầng ứng dụng của giao thức TCP/IP. Do đặc điểm này, SSL
có thể được dùng trong hầu hết mọi hệ điều hành hỗ trợ TCP/IP mà không cần phải chỉnh sửa
nhân của hệ thống hoặc ngăn xếp TCP/IP. Điều này mang lại cho SSL sự cải tiến mạnh mẽ so

với các giao thức khác như IPSec (IP Security Protocol). Vì giao thức này đòi hỏi nhân hệ điều
hành phải hỗ trợ và chỉnh sửa ngăn xếp TCP/IP. SSL cũng có thể dễ dàng vượt qua tường lửa và
proxy, cũng như NAT (Network Address Translation) mà không cần nguồn cung cấp.
SSL hoạt động như thế nào? Biểu đồ dưới đây sẽ chỉ ra một cách đơn giản với từng bước quá
trình thiết lập kết nối SSL giữa máy khách (client – dùng một đường dẫn web browser) và máy
chủ (server – dùng một SSL web server)
Biểu đồ 2. Từng bước thành lập một kết nối SSL
Như bạn thấy trên hình, quá trình thiết lập kết nối SSL bắt đầu bằng việc trao đổi các tham số mã
hoá và sau đó xác nhận các server một cách tuỳ ý (dùng gia thức SSL Handshake). Nếu “bắt tay”
(Handshake) thành công, cả hai chiều đều chấp nhận bộ mã hoá chung và các khoá mã hoá, thì
dữ liệu ở tầng ứng dụng (thông thường dùng HTTP, nhưng cũng có thể là một giao thức khác) có
thể được gửi thông qua đường hầm (tunnel) mã hoá (dùng SSL Record Layer).
Trong thực tế, tiến trình trên còn phức tạp hơn một chút. Để tránh những cái “bắt tay” không cần
thiết, một số tham số mã hoá được giữ lại. Các thông báo được gửi đi. Bộ mã hoá cũng có thể
được thay đổi. Tuy nhiên, bất chấp các đặc điểm kĩ thuật đó, cách thức phổ biến nhất của tiến
trình này làm việc thực sự như trên.
SSL, PCT, TLS và WTLS (nhưng không có SSH)
Mặc dù SSL là giao thức được biết đến nhiều nhất và phổ biến nhất, nhưng nó không phải là giao
thức duy nhất dùng cho mục đích an toàn và giao vận trong web. Cũng khá quan trọng để biết
rằng, từ sau phát minh SSL v1.0 ra đời , có ít nhất năm giao thức khác hoặc ít hơn hoặc nhiều
hơn đóng vai trò quan trọng trong an ninh truy cập World Wide Web. Cụ thể:
SSL v2.0
Phiên bản này được tạo ra bởi Netscape Communications năm 1994. Mục đích chính của giao
thức này là cung cấp an toàn cho các giao dịch trên World Wide Web. Thật không may, nhanh
chóng sau đó người ta thấy con số yếu kém về an toàn trong phiên bản đầu của giao thức SSL
này. Do đó làm cho nó kém tin cậy hơn với cách dùng mang tính chất thương mại.
• Cấu trúc của MAC yếu.
• Có khả năng để các nhóm bắt buộc dùng bộ mã hoá yếu
• Không bảo vệ quá trình “bắt tay”
• Có khả năng những kẻ tấn công dùng kiểu cắt xén (truncation attack)

PCT v1.0
Được phát triển bởi Microsoft vào năm 1995. PCT (Privacy Communication Technology ) v1.0
địa chỉ hoá một số điểm yếu của SSL 2.0 và đặt ra mục tiêu là thay thế SSL. Tuy nhiên giao thức
này đã không bao giờ thu được kết quả phổ biến như là SSL v3.0.
SSL v3.0
Được phát hành vào năm 1996 bởi Netscape Communications. SSL v3.0 giải quyết hầu hết các
vấn đề của SSL v2.0 và kết hợp rất nhiều thành phần của PCT. Nhanh chóng sau đó nó trở thành
giao thức phổ biến nhất cho an toàn truyền thông trên World Wide Web.
TLS v1.0 (được biết đến như là SSL v3.1)
Được đưa ra bởi IETF vào năm 1999 (RFC 2246). Giao thức này dựa trên SSL v3.0 và PCT. Nó
cân bằng cả hai cách thức của Netscape và Microsoft. Cũng cần chú ý rằng, mặc dù TLS dựa trên
SSL, nhưng nó không phải là phiên bản sau tương thích 100% với các bản trước nó. IETF đã
thực hiện môt số cải tiến về an toàn. Chẳng hạn như dùng HMAC thay vì MAC, dùng phép tính
toán khác trong bảo mật của máy chủ và tài liệu khoá (key), thêm các bộ chỉnh sửa, không hỗ trợ
bộ mã hoá Fortezza , v.v… Kết quả của những nâng cấp này là các giao thức không hoạt động
được một cách đầy đủ. Cuối cùng TLS cũng rơi vào lãng quên so với SSL v3.0.
WTLS
Phiên bản “di động và không dây” của giao thức TLS, sử dụng giao thức UDP như là một hãng
truyền thông. WTLS được thiết kế và tối ưu cho các băng thông thấp hơn, các tiến trình nhỏ hơn
với các thiết bị di động cho phép dùng WAP. WTLS đưa ra cùng giao thức WAP 1.1 bởi WAP
Forum. Tuy nhiên, sau khi giao thức WAP 2.0 được giới thiệu, WTLS bị thay thế bởi một phiên
bản nguyên trạng của TLS với mức an toàn cao hơn. Nó không cần phải giải mã hay mã hoá lại
lưu lượng tại cổng vào của WAP.
Vì sao giao thức SSH lại không được dùng cho mục đích đảm bảo an ninh khi truy cập
WWW?
Có một vài lí do! Đầu tiên, ngay từ khi bắt đầu, TLS và SSL đã được thiết kế cho các phiên an
ninh mạng (HTTP), trong khi SSH được lùi lại để thay thế cho Telnet và FTP. SSL không làm gì
hơn là “bắt tay” và thiết lập các “đường hầm mã hoá” . Và tại cùng thời gian đó, SSH đưa ra
cách đăng nhập giữa người - máy, truyền tải các file an toàn, hỗ trợ cho nhiều bước kiểm tra
quyền (bao gồm mật khẩu, các khoá chung, Kerberos…). Mặt khác SSL/TLS dựa trên các chứng

chỉ X.509v3 và PKT, các chứng chỉ này tạo nên sự phân phối và quản lí khả năng thẩm định
quyền hạn dễ dàng hơn nhiều. Với những lí do này và một số lí do khác nữa làm cho SSL/TLS
ngày càng phù hợp hơn an toàn truy cập WWW và các kiểu khác tương tự trong truyền thông,
bao gồm SMTP, LDAP… trong khi SSH ngày càng thuận tiện cho việc quản lí các hệ thống từ
xa.
Nói tóm lại, mặc dù trong thực tế có nhiều giao thức “an toàn” nhưng ta chỉ nên dùng hai giao
thức giao dịch web (ít nhất tại thời điểm này) là: TLS v1.0 và SSL v3.0. Cả hai đều được nhấn
mạnh trong loạt bài này với cái tên đơn giản là SSL/TLS. Bởi những điểm yếu kém đã được biết
đến của SSL v2.0 và “lỗ hổng WAP” nổi tiếng của WTLS, chúng ta nên tránh dùng các giao thức
này, hoặc ít nhất là hạn chế ở mức thấp nhất.
Những yêu cầu của phần mềm
Trong phần tiếp theo của loạt bài này, chúng ta sẽ được biết cách cấu hình Apache 2.0 có hỗ trợ
SSL/TLS, dùng mô hình mod_ssl. Trước khi đi xa hơn, bạn đọc nên download mã nguồn của
phiên bản mới nhất Apache 2.0 từ website của Apache. Hầu hết các ví dụ cũng làm trong Apache
1.3.x. Trong trường hợp này mod_ssl cần được download riêng rẽ từ mã nguồn của Apache trên
website mod_ssl.
Các ví dụ cụ thể trong bài này hầu hết làm trên các hệ điều hành Linux, giống Linux và BSD –
hệ thống điều hành cơ bản. Đòi hỏi duy nhất cho hệ điều hành là phải có cả thư viện OpenSSL và
GCC.
Là một web browser mặc định, MS Internet Explorer đã được chọn cho bài thử nghiệm của
chúng ta chủ yếu bởi vì sự quá phổ biến của nó. Tuy nhiên, bất kì một web brower hiện đại nào
khác cũng có thể được dùng như FireFox, Mozilla, Netscape, Safari, Opera…
Cài đặt Apache hỗ trợ SSL/TLS
Bước đầu tiên để cài đặt phần mềm Apache có hỗ trợ SSL/TLS là cấu hình và cài đặt Apache 2
web server, tạo ra một người dùng và một nhóm được đặt tên là “apache”. Một cách cài đặt an
toàn đã được xuất bản trên SecurityFocus, trong bài báo Security Apache 2.0: Step-by-Step. Chỉ
có một điểm khác nhau duy nhất là tiến trình để thiết lập mod_ssl và mod_setenvif. Nó đòi hỏi
phải tương thích với một số phiên bản của Internet Explorer như sau (thay đổi được chỉ ra trong
phần in đậm):
./configure \

prefix=/usr/local/apache2 \
with-mpm=prefork \
enable-ssl \
disable-charset-lite \
disable-include \
disable-env \
enable-setenvif \
disable-status \
disable-autoindex \
disable-asis \
disable-cgi \
disable-negotiation \
disable-imap \
disable-actions \
disable-userdir \
disable-alias \
disable-so
Sau khi cấu hình xong, chúng ta có thể cài đặt Apache theo thư mục gốc:
make
su
umask 022
make install
chown -R root:sys /usr/local/apache2
Xem tiếp Phần I
Cấu hình SSL/TLS
Trước khi chạy Apache lần đầu tiên, chúng ta cũng cần cung cấp cấu hình ban đầu và tham gia
một số nội dung web mẫu. Ít nhất, chúng ta cần theo các bước sau (như là Root):
1. Tạo một số nội dung web mẫu mà sẽ được đáp ứng qua SSL/TLS:
umask 022
mkdir /www

echo " \
Test works." > /www/index.html
chown -R root:sys /www
2. Thay thế file cấu hình Apache mặc định (thông thường được tìm thấy trong
/usr/local/apache2/conf/httpd.conf) bằng một cái mới, dùng nội dung sau (tối ưu hoá
mức an toàn và sự thực thi):
# =================================================
# Basic settings
# =================================================
User apache
Group apache
ServerAdmin
ServerName www.seccure.lab
UseCanonicalName Off
ServerSignature Off
HostnameLookups Off
ServerTokens Prod
ServerRoot "/usr/local/apache2"
DocumentRoot "/www"
PidFile /usr/local/apache2/logs/httpd.pid
ScoreBoardFile /usr/local/apache2/logs/httpd.scoreboard
DirectoryIndex index.html
# =================================================
# HTTP and performance settings
# =================================================
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 30
MinSpareServers 5

MaxSpareServers 10
StartServers 5
MaxClients 150
MaxRequestsPerChild 0
# =================================================
# Access control
# =================================================
Options None
AllowOverride None
Order deny,allow
Deny from all
Order allow,deny
Allow from all
# =================================================
# MIME encoding
# =================================================
TypesConfig /usr/local/apache2/conf/mime.types
DefaultType text/plain
AddEncoding x-compress .Z
AddEncoding x-gzip .gz .tgz
AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz
AddType application/x-tar .tgz
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
# =================================================
# Logs
# =================================================
LogLevel warn
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-

Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
ErrorLog /usr/local/apache2/logs/error_log
CustomLog /usr/local/apache2/logs/access_log combined
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"
# =================================================
# SSL/TLS settings
# =================================================
Listen 0.0.0.0:443
SSLEngine on
SSLOptions +StrictRequire
SSLRequireSSL
SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM
SSLMutex file:/usr/local/apache2/logs/ssl_mutex
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect file:/dev/urandom 1024
SSLSessionCache shm:/usr/local/apache2/logs/ssl_cache_shm
SSLSessionCacheTimeout 600
SSLPassPhraseDialog builtin
SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt
SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key
SSLVerifyClient none
SSLProxyEngine off
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
3. Chú ý: Các bạn nên thay đổi một số giá trị trong file cấu hình trên. Chẳng hạn như tên của
web server, địa chỉ e-mail của người quản trị.v.v….
4. Tham gia cấu trúc lại thư mục khoá private của web server, các chứng chỉ, và danh sách
thu hồi chứng chỉ (CRLs).
umask 022
mkdir /usr/local/apache2/conf/ssl.key
mkdir /usr/local/apache2/conf/ssl.crt
mkdir /usr/local/apache2/conf/ssl.crl
5. Tạo một dịch vụ “tự kí nhận” (nó sẽ chỉ được dùng cho mục đích kiểm tra – các chứng chỉ
thực của bạn nên lấy từ một CA thích hợp như Verisign):
openssl req \
-new \
-x509 \
-days 30 \
-keyout /usr/local/apache2/conf/ssl.key/server.key \
-out /usr/local/apache2/conf/ssl.crt/server.crt \
-subj '/CN=Test-Only Certificate'
Kiểm tra phần cài đặt
Tại thời điểm này, chúng ta có thể bắt đầu Apache hỗ trợ SSL/TLS như sau:
/usr/local/apache2/bin/apachectl startssl
Apache/2.0.52 mod_ssl/2.0.52 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide us with the pass phrases.
Server 127.0.0.1:443 (RSA)
Enter pass phrase:*************
Ok: Pass Phrase Dialog successful.
Sau khi máy chủ bắt đầu, chúng ta có thể cố gắng kết nối tới nó bằng cách trỏ vào web browser

với một đường dẫn URL có dạng: ver (trong trường hợp của
chúng ta là )
Trong một vài phút, chúng ta sẽ thấy cảnh báo nói rằng có vấn đề với việc kiểm chứng sự xác
nhận web server chúng ta muốn truy cập. Minh hoạ trong hình 3 là một ví dụ từ MS Internet
Explorer 6.0.
Hình 3. Cảnh báo trước của IE 6.0.
Sự xuất hiện của cảnh báo trên đúng một cách hoàn hảo! Chúng ta nên nhận cảnh báo này vì hai
lí do sau:
• Web browser không biết Certificate Authority (quyền hạn chứng chỉ), được cung cấp bởi
chứng chỉ của web server (và không thể biết, bởi vì chúng ta đang dùng chứng chỉ tự kí –
selfsigned certificate).
• CN (Common Name) – Tên chung được cho bởi chứng chỉ không nối ghép tên của
website - tại thời điểm nó là chứng chỉ chỉ đọc (Text-only Certificate), và nó sẽ là tên
miền một cách đầy đủ của web server (ví dụ như: www.seccure.lab)
Sau khi thực thi với Internet Explorer, chúng ta nên xem nội dung web sau, như trong hình minh
hoạ 4:
Hình 4. Trang web làm việc mẫu của SSL.
Một điều cần chú ý, có một cái khoá vàng ở cuối của web browser. Điều đó có nghĩa là kết nối
SSL đã được thiết lập thành công. Giá trị 128 bit nói lên rằng khoá đối xứng được dùng để mã
hoá giao dịch có độ dài 128 bit. Và nó đủ mạnh (ít nhất tại thời điểm này) để bảo vệ giao thông
mạng khỏi sự xâm nhập trái phép.
Nếu chúng ta kích đúp vào biểu tượng khoá, chúng ta sẽ thấy các thuộc tính của chứng chỉ
website, như được chỉ ra trong hình 5:
Hình 5. Các chi tiết của chứng chỉ tự kí (sekf-signed certificate)
Gở rối
Nếu vì một lí do nào đó chúng ta không thể truy cập được vào website, có một chức năng chẩn
đoán hữu ích là “s_client”, nằm trong thư viện OpenSSL. Nó có thể được dùng để gỡ rối các kết
nối SSL/TLS. Ví dụ sau chỉ ra cách dùng chức năng này như thế nào:
/usr/bin/openssl s_client -connect localhost:443
CONNECTED(00000003)

depth=0 /CN=Test-Only Certificate
verify error:num=18:self signed certificate
verify return:1
depth=0 /CN=Test-Only Certificate
verify return:1

Certificate chain
0 s:/CN=Test-Only Certificate
i:/CN=Test-Only Certificate

Server certificate
BEGIN CERTIFICATE
MIICLzCCAZigAwIBAgIBADANBgkqhkiG9w0BAQQFADAgMR4wHAYDVQQDExVUZXN0
LU9ubHkgQ2VydGlmaWNhdGUwHhcNMDQxMTIyMTg0ODUxWhcNMDQxMjIyMTg0ODUx
WjAgMR4wHAYDVQQDExVUZXN0LU9ubHkgQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAMEttnihJ7JpksdToPi5ZVGcssUbHn/G+4G43OiLhP0i
KvYuqNxBkSqqM1AanR0BFVEtVCSuq8KS9LLRdQLJ/B1UTMOGz1Pb14WGsVJS+38D
LdLEFaCyfkjNKnUgeKMyzsdhZ52pF9febB+d8cLmvXFve28sTIxLCUK7l4rjT3Xl
AgMBAAGjeTB3MB0GA1UdDgQWBBQ50isUEV6uFPZ0L4RbRm41+i1CpTBIBgNVHSME
QTA/gBQ50isUEV6uFPZ0L4RbRm41+i1CpaEkpCIwIDEeMBwGA1UEAxMVVGVzdC1P
bmx5IENlcnRpZmljYXRlggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQAD
gYEAThyofbK3hg8AJXbAUD6w6+mz6dwsBmcTWLvYtLQUh86B0zWnVxzSLDmwgdUB
NxfJ7yfo0PkqNnjHfvnb5W07GcfGgLx5/U3iUROObYlwKlr6tQzMoysNQ/YtN3pp
52sGsqaOOWpYlAGOaM8j57Nv/eXogQnDRT0txXqoVEbunmM=
END CERTIFICATE
subject=/CN=Test-Only Certificate
issuer=/CN=Test-Only Certificate

No client certificate CA names sent

SSL handshake has read 1143 bytes and written 362 bytes

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
SSL-Session:
Protocol : SSLv3
Cipher : DHE-RSA-AES256-SHA
Session-ID:
56EA68A5750511917CC42A1B134A8F218C27C9C0241C35C53977A2A8BBB9986A
Session-ID-ctx:
Master-Key:
303B60D625B020280F5F346AB00F8A61A7C4BEA707DFA0ED8D2F52371F8C4F08
7FB6EFFC02CE3B48F912D2C8929DB5BE
Key-Arg : None
Start Time: 1101164382
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)

GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Mon, 22 Nov 2004 22:59:56 GMT
Server: Apache
Last-Modified: Mon, 22 Nov 2004 17:24:56 GMT
ETag: "5c911-46-229c0a00"
Accept-Ranges: bytes
Content-Length: 70
Connection: close
Content-Type: text/html Test works.
closed
Chức năng s_client có nhiều tuỳ chọn hữu ích. Chẳng hạn như tắt/mở (on/off) một giao thức cụ

thể (-ssl2 , -ssl3, -tls1). Sau đó khởi động lại Apache và kiểm tra các file đăng nhập
(/usr/local/apache2/logs/) để có thêm thông tin.
Chúng ta cũng có thể dùng Ethereal hoặc ssldump. Chúng ta có thể xem một cách thụ động các
thông báo Handshake của SSL, và cố gắng tìm ra lí do lỗi nếu không có những công cụ này.
Một màn hình nhỏ thực thi việc này trên Ethereal được mô tả trong hình 6.
Hình 6. Màn hình Ethereal với phương thức SSL Handshake.
Kết luận phần I
Việc cài đặt và chạy Apache 2 secure cùng giao thức SSL và một chứng chỉ mẫu đã kết thúc
phần một của loạt bài này. Trong phần hai tới các bạn sẽ được giới thiều về các thiết lập an ninh
và sự thực thi cho mod_ssl, cũng như tiến trình tạo ra một chứng chỉ web server phù hợp.
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ình và gỡ rối
phần 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ẽ được hướng dẫn làm thế nào để tạo ra một Quyền hạn chứng chỉ (Certification Authority) nội
bộ và một chứng chỉ SSL dựa 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ản mô tả chi tiết
cả 30 hướng dẫn này có thể tìm thấy trong Apache's mod_ssl documentation. Phần này chỉ tập
trung vào các 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ì máy chủ (hay
máy trạm ảo) sẽ không dùng SSL/TLS được
SSLRequireSSL
Phải đặt ở chế độ cho phép, nếu không người dùng có thể
truy cập nội dung web qua các yêu cầu HTTP thông
thường mà 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ầu
hết các web browser hiện nay đểu hỗ trợ cả hai. Vì thế
chúng ta có thể vô hiệu hoá SSL v2.0 một cách an toàn.
SSLCipherSuite
SSLProxyCipherSuite
Để tạo ra phương thức mã hoá mạnh, tham số này nên đặt
ở mức HIGH (>168 bits) và MEDIUM (128 bits). Mức
LOW (<56 bits) và NULL (không mã hoá) đặt bộ mã hoá
vào trạng thái bị vô hiệu hoá. Nên vô hiệu hoá tất cả các
bộ mã hoá hỗ trợ nhận 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ần mã hoá mạnh thì dùng bộ mã hoá
EXPORT (56 bit và 40 bit). Điều cuối cùng, chúng ta nên
dùng SHA1 hơn là MD5. Bởi vì SHA1 được coi là 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ã hoá nào như
sau:
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ùng.
SSLRandomSeed
Để khởi động Apache nên cài đặt để sử dụng thiết bị
ngẫu nhiên giả (/dev/urandom) và/hoặc EGD (Entrophy

Gathering Daemon). Trước khi mỗi kết nối SSL mới
được thiết lập, nên cấu hình lại để dùng nguồn được cài
đặt sẵn, /dev/urandom hoặc EGD. Không nên dùng
/dev/random trong cả hai trường hợp. 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êu cầu HTTP
song song (ví dụ khi web browser tải nhiều hình ảnh
trong một khoảng thời gian), SSL caching nên được
dùng. Nó sẽ thiết lập để dùng bộ nhớ chia sẻ (SHM),
hoặc DBM. Khi thiết lập này là "none", thực thi của web
server có thể giảm một cách đáng kể.
SSLSessionCacheTime
out
Giá trị này mô tả số giây thời gian sau khi đường vào
trong SSLSessionCache hết hiệu lực. Nó nên được đặt ít
nhất là 300-600 giây. Tuy nhiên thời gian thực phụ thuộc
vào thời gian 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ảng 15 phút, thì giá 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ên
đặt chúng ở chế độ "optional_no_ca". Bởi vì ngược lại
với bộ nhận dạng PKI, những chỗ nào client được nhận
dạng, chúng phải đưa ra các chứng chỉ phù hợp.
“Optional” thỉnh thoảng được dùng (phụ thuộc xem là

cần hay không), tuy nhiên nó có thể không làm 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ứng chỉ
client được kí bởi Root CA, nên đặt là 1…
SSLProxyEngine
Nên vô hiệu hoá (đặt ở chế độ disable), nếu cơ chế
SSL/TLS 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 httpd.conf
như sau:
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:
+EXP
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
CustomLo
g
Để ghi thông tin về tham số của SSL (yêu cầu tối thiểu: phiên bản của
giao thức và bộ mã hoá được chọn) chúng ta nên dùng các giá trị 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àm keep-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ặc 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ên, giúp người
đọc 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ủa chúng ta
không thể kiểm tra được nhận dạng của web server. Trong bài đầu tiên, chúng ta đã dùng một
chứng chỉ web server đượ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à các giao 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, được biết
đến như 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ư
đất nước (C), bang (S), 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 web
server. 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ùng hay 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à
rất quan trọng. Các khoá private của web server có nên được mã hoá hay không? Có nhiều ý kiến
được đưa ra, 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à còn 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ày khá
khó chịu 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ĩa là web
server bị 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ường hợp 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ặc là phá huỷ hoặc là 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 vệ chúng
chống lại 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ùng của bất kì
phương 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ặc dùng trong
môi trường 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ể được tạo ra
như sau:
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 (-
days 365), và sẽ được kí bằng cách dùng thuật toán SHA1 (-sha1). Khoá private RSA có độ dài
1024 bit (-newkey rsa: 10224), và không cần bảo vệ bằng mật khẩu (-nodes). Chứng chỉ và cặp
đôi khoá public/private sẽ được tạo trong hai file “server.crt” và “server.key”. Tên của khu vực
này là “Seccure 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 được nhận dạng của web server. Trong môi trường Windows, điều này được thể hiện
trong hình minh hoạ 1 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ếp 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ó một con số 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êu cầu chứng chỉ các 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ên chọn một 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ồm: Thawte, Verisgn 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ầu
chứng chỉ (trong request.pem) như sau:
openssl req \
-new \
-sha1 \
-newkey rsa:1024 \

-nodes \