BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ TP.HCM
KHOA TRUNG CÔNG NGHỆ THÔNG TIN

BÁO CÁO ĐỀ ÁN THIẾT BỊ MẠNG VÀ QUẢN TRỊ MẠNG

Đề tài:Giao thức bảo mật SSL

GVHD:Huỳnh Quốc Bảo
Nhóm 1

TP.HCM, 2011


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

MỤC LỤC
Phần

trang

I - Lịch sử phát triển của giao thức SSL & TLS:...................................2
II - Cấu trúc của giao thức SSL:.................................................................3
III - SSL Record Protocol :............................................................................8
IV - SSL Handshake Protocol:..............................................................11
V - Các thuật toán mã hoá dùng trong SSL:.......................................14
1.Các bộ mã hoá sử dụng thuật toán trao đổi khoá RSA:
2.SSL handshake:

VI - Phân tích bảo mật:..........................................................................17

2


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

CÁC GIAO THỨC BẢO MẬT SSL VÀ TLS

I - Lịch sử phát triển của giao thức SSL & TLS:
Như chúng ta đã biết có hai giao thức bảo mật quan trọng lớp vận chuyển (Layer Transport)
có tầm quan trọng cao nhất đối với sự bảo mật của các trình ứng dụng trên Web: đó là hai
giao thức SSL và TLS.
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ổ
3


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

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.
Nói chung, có một số khả năng để bảo vệ bằng mật mã lưu lượng dữ liệu HTTP. Ví dụ, vào
những năm 1990, tập đoàn CommerceNet đã đề xuất S-HTTP mà về cơ bản là một cải tiến bảo
mật của HTTP. Một phần thực thi của S-HTTP đã làm cho có sẵn công cộng trong một phiên
bản được chỉnh sửa của trình duyệt Mosaic NCSA mà những người dùng phải mua (trái với
trình duyệt Mo NCSA "chuẩn" có sẵn công cộng và miễn phí trên Internet).
Tuy nhiên, cùng thời điểm Netscape Communication đã giới thiệu SSL và một giao thức tương
ứng với phiên bản đầu tiên của Netscape Navigator, Trái với tập đoàn CommerceNet,
Netscape Communications đã không tính phí các khách hàng của nó về việc thực thi giao thức
bảo mật của nó. Kết quả, SSL trở thành giao thức nổi bật để cung cấp các dịch vụ bảo mật cho
lưu lượng dữ liệu HTTP 1994 và S-HTTP lặng lẽ biến mất.
Cho đến bây giờ, có ba phiên bản của SSL:
1. SSL 1.0: được sử dụng nội bộ chỉ bởi Netscape Communications. Nó chứa một số khiếm
khuyết nghiêm trọng và không bao giờ được tung ra bên ngoài.
2. SSL 2.0: được kết nhập vào Netscape Communications 1.0 đến 2.x. Nó có một số điểm yếu
liên quan đến sự hiện thân cụ thể của cuộc tấn công của đối tượng trung gian. Trong một nỗ

lực nhằm dùng sự không chắc chắn của công chúng về bảo mật của SSL, Microsoft cũng đã
giới thiệu giao thức PCT (Private Communication Technology) cạnh tranh trong lần tung ra
Internet Explorer đầu tiên của nó vào năm 1996.
3. Netscape Communications đã phản ứng lại sự thách thức PCT của Microsoft bằng cách giới
thiệu SSL 3.0 vốn giải quyết các vấn đề trong SSL 2.0 và thêm một số tính năng mới. Vào thời
điểm này, Microsoft nhượng bộ và đồng ý hỗ trợ SSL trong tất cả các phiên bản phần mềm
dựa vào TCP/IP của nó (mặc dù phiên bản riêng của nó vẫn hỗ trợ PCT cho sự tương thích
ngược).
Thông số kỹ thuật mới nhất của SSL 3.0 đã được tung ra chính thức vào tháng 3 năm 1996.
Nó được thực thi trong tất cả các trình duyệt chính bao gồm ví dụ Microsoft Internet Explorer
3.0 (và các phiên bản cao hơn), Netscape Navigator 3.0 (và các phiên bản cao hơn), và Open.
Như được thảo luận ở phần sau trong chương này, SSL 3.0 đã được điều chỉnh bởi IETF TLS
WG. Thực tế, thông số kỹ thuật giao thức TLS 1.0 dẫn xuất từ SSL 3.0.
II - Cấu trúc của giao thức SSL:
Cấu trúc của SSL và giao thức SSL tương ứng được minh họa trong hình 1.1(Cấu trúc SSL
và giao thức SSL). Theo hình này, SSL ám chỉ một lớp (bảo mật) trung gian giữa lớp vận
chuyển (Transport Layer) và lớp ứng dụng (Application Layer). SSL được xếp lớp lên trên một
dịch vụ vận chuyển định hướng nối kết và đáng tin cậy, chẳng hạn như được cung cấp bởi TCP.
Về khả năng, nó có thể cung cấp các dịch vụ bảo mật cho các giao thức ứng dụng tùy ý dựa
vào TCP chứ không chỉ HTTP. Thực tế, một ưu điểm chính của các giao thức bảo mật lớp vận
4


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

chuyển (Transport layer) nói chung và giao thức SSL nói riêng là chúng độc lập với ứng dụng
theo nghĩa là chúng có thể được sử dụng để bảo vệ bất kỳ giao thức ứng dụng được xếp lớp
lên trên TCP một cách trong suốt. Hình 1.1 minh họa một số giao thức ứng dụng điển hình bao
gồm NSIIOP, HTTP, FTP, Telnet, IMAP, IRC, và POP3. Tất cả chúng có thể được bảo vệ bằng cách

xếp lớn chúng lên trên SSL (mẫu tự S được thêm vào trong các từ ghép giao thức tương ứng
chỉ định việc sử dụng SSL). Tuy nhiên, chú ý rằng SSL có một định hướng client-server mạnh
mẽ và thật sự không đáp ứng các yêu cầu của các giao thức ứng dụng ngang hàng.
hình 1.1: Cấu trúc của SSL và giao thức SSL

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
5


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

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.
Tóm lại, giao thức SSL cung cấp sự bảo mật truyền thông vốn có ba đặc tính cơ bản:
1. Các bên giao tiếp (nghĩa là client và server) có thể xác thực nhau bằng cách sử dụng mật
mã khóa chung.
2. Sự bí mật của lưu lượng dữ liệu được bảo vệ vì nối kết được mã hóa trong suốt sau khi
một sự thiết lập quan hệ ban đầu và sự thương lượng khóa session đã xảy ra.
3. Tính xác thực và tính toàn vẹn của lưu lượng dữ liệu cũng được bảo vệ vì các thông báo
được xác thực và được kiểm tra tính toàn vẹn một cách trong suốt bằng cách sử dụng MAC.
Tuy nhiên, điều quan trọng cần lưu ý là SSL không ngăn các cuộc tấn công phân tích lưu
lượng. Ví dụ, bằng cách xem xét các địa chỉ IP nguồn và đích không được mã hóa và các sô
cổng TCP, hoặc xem xét lượng dữ liệu được truyền, một người phân tích lưu lượng vẫn có thể
xác định các bên nào đang tương tác, các loại dịch vụ đang được sử dụng, và đôi khi ngay cả
dành được thông tin về các mối quan hệ doanh nghiệp hoặc cá nhân. Hơn nữa, SSL không
ngăn các cuộc tấn công có định hướng dựa vào phần thực thi TCP, chẳng hạn như các cuộc
tấn công làm tràn ngập TCP SYN hoặc cưỡng đoạt session.
Để sử dụng sự bảo vệ SSL, cả client lẫn server phải biết rằng phía bên kia đang sử dụng SSL.
Nói chung, có ba khả năng để giải quyết vấn đề này:

1. Sử dụng các số cổng chuyên dụng được dành riêng bởi Internet Asigned Numbers
Authority (IANA). Trong trường hợp này, một số cổng riêng biệt phải được gán cho mọi giao
thức ứng dụng vốn sử dụng SSL.
2. Sử dụng số cổng chuẩn cho mọi giao thức ứng dụng và để thương lượng các tùy chọn
bảo mật như là một phần của giao thức ứng dụng (bây giờ được chỉnh sửa đôi chút).
3. Sử dụng một tùy chọn TCP để thương lượng việc sử dụng một giao thức bảo mật, chẳng

6


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

hạn như SSL trong suốt giai đoạn thiết lập nối kết TCP thông thường.
Sự thương lượng dành riêng cho ứng dụng của các tùy chọn bảo mật (nghĩa là khả năng thứ
hai) có khuyết điểm là đòi hỏi mọi giao thức ứng dụng được chỉnh sửa để hiểu tiến trình
thương lượng. Ngoài ra, việc xác định một tùy chọn TCP (nghĩa là khả năng thứ ba) là một
giải pháp tốt, nhưng đó không được thảo luận nghiêm túc cho đến bây giờ. Thực tế, các số
cổng riêng biệt đã được dành riêng và được gán bởi IANA cho mọi giao thức ứng dụng vốn có
thể chạy trên SSL hoặc TLS (nghĩa là khả năng thứ nhất). Tuy nhiên, hãy chú ý việc sử dụng
các số cổng riêng biệt cũng có khuyết điểm là đòi hỏi hai nối kết TCP nếu client không biết
những gì mà server hỗ trợ. Trước tiên, client phải nối kết với cổng an toàn và sau đó với cổng
không an toàn hay ngược lại. Rất có thể các giao thức sau này sẽ hủy bỏ phương pháp này và
tìm khả năng thứ hai. Ví dụ, SALS (Simple Authentication và Security Layer) xác định một phù
hợp để thêm sự hỗ trợ xác thực vào các giao thức ứng dụng dựa vào kết nối. Theo thông số kỹ
thuật SALS, việc sử dụng các cơ chế xác thực có thể thương lượng giữa client và server của
một giao thức ứng dụng đã cho.
Các số cổng được gán bởi IANA cho các giao thức ứng dụng vốn chạy trên SSL/TLS được
tóm tắt trong bảng 1.2 và được minh họa một phần trong hình 1.1. Ngày nay, "S" chỉ định việc
sử dụng SSL được thêm (hậu tố) nhất quán vào các từ ghép của các giao thức ứng dụng

tương ứng (trong một số thuật ngữ ban đầu, S được sử dụng và được thêm tiền tố một cách
không nhất quán và một số từ ghép).
Bảng1.2: Các số cổng được gán cho các giao thức ứng dụng chạy trên TLS/SSL.

Từ
khóa
Nsiiop

Cổn
g
261

https
Smtps
Nntps
Ldaps
Ftpsdata
Ftps

443
465
563
636
989

Tenets
Imaps
Pop3s

992

994
995

990

Mô tả
Dịch vụ tên IIOP trên
TLS/SSL
HTTP trên TLS/SSl
SMTP trên TLS/SSL
NNTP trên TLS/SSL
LDAP trên TLS/SSL
FTP (dữ liệu) trên
TLS/SSL
FTP (Điều khiển) trên
TLS/SSL
TELNET trên TLS/SSL
IRC trên TLS/SSL
POP3 trên TLS/SSL

7


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

Nói chung, một session SSL có trạng thái và giao thức SSL phải khởi tạo và duy trì thông tin
trạng thái ở một trong hai phía của session. Các phần tử thông tin trạng thái session tương
ứng bao gồm một session ID, một chứng nhận ngang hàng, một phương pháp nén, một thông
số mật mã, một khóa mật chính và một cờ vốn chỉ định việc session có thể tiếp tục lại hay

không, được tóm tắt trong bảng 1.3. Một session SSL có thể được sử dụng trong một số kết nối
và các thành phần thông tin trạng thái nối kết tương ứng được tóm tắt trong bảng 1.4. Chúng
bao gồm các tham số mật mã, chẳng hạn như các chuỗi byte ngẫu nhiên server và client, các
khóa mật MAC ghi server và client, các khóa ghi server và client, một vector khởi tạo và một
số chuỗi. Ở trong hai trường hợp, điều quan trọng cần lưu ý là các phía giao tiếp phải sử dụng
nhiều session SSL đồng thời và các session có nhiều nối kết đồng thời.
Bảng 1.3 Các thành phần thông tin trạng thái Session SSL
Thành Phần
Session ID
Peer certificate
Compression
method
Cipher spec
Master secret
Is resumable

Mô tả
Định danh được chọn bởi server để nhận
dạng một trạng thái session hoạt động hoặc
có thể tiếp tục lại.
Chứng nhân X.509 phiên bản 3 của thực thể
ngang hàng.
Thuật toán dừng để nén dữ liệu trước khi
mã hóa
Thông số của các thuật toán mã hóa dữ liệu
và MAC
Khóa mật 48-byte được chia sẻ giữa client và
server.
Cờ vốn biểu thị session có thể được sử dụng
để bắt đầu các nối kết mới hay không.


Bảng 1.4 Các thành phần thông tin trạng thái nối kết SSL
Thành Phần
Ngẫu nhiên
server và
client
Khóa mật MAC
ghi server
Khóa mật MAC
ghi client
Khóa ghi
server
Khóa ghi client
Initialization

Mô tả
Các chuỗi byte được chọn bởi server và client
cho mỗi nối kết.
Khóa mật được sử dụng cho các hoạt động
MAC trên dữ liệu được ghi bởi server.
Khóa mật được sử dụng cho các hoạt động
MAC trên dữ liệu được ghi bởi client.
Khóa được sử dụng cho việc mã hóa dữ liệu
bởi server và giải mã bởi client
Khóa được sử dụng để mã khóa dữ liệu bởi
client và giải mã bởi server.
Trạng thái khởi tạo cho một mật mã khối
8



TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

vector

Số chuỗi

trong chế độ CBC. Trường này được khởi tạo
đầu tiên bởi SSL Handshake Player. Sau đó,
khối text mật mã sau cùng từ mỗi bản ghi
được dành riêng để sử dụng vởi bản ghi sau
đó.
Mỗi phía duy trì các số chuỗi riêng biệt cho
các thông báo được truyền và được nhận cho
mỗi nối kết.

Như được minh họa trong hình 1.1, giao thức SSL gồm hai phần chính, SSL Record Protocol
và một số giao thức con SSL được xếp lớp trên nó:
- Record OK được xếp lớp trên một dịch vụ lớp vận chuyển định hướng nối kết và đáng tin cậy,
chẳng hạn như được cung cấp bởi TCP và cung cấp sự xác thực nguồn gốc thông báo, sự bí
mật dữ liệu và dữ liệu.
- Các dịch vụ toàn vẹn (bao gồm nhưng thứ như chống xem lại).
- Các giao thức con SSL được xếp lớp trên SSL Record Protocol để cung cấp sự hỗ trợ cho việc
quản lý session SSL và thiết lập nối kết.
Giao thức con SSL quan trọng nhất là SSL Handshake Protocol. Lần lượt giao thức này là
một giao thức xác thực và trao đổi khóa vốn có thể được sử dụng để thương lượng, khởi tạo
và đồng bộ hóa các tham số bảo mật và thông tin trạng thái tương ứng được đặt ở một trong
hai điểm cuối của một session hoặc nối kết SSL.
Sau khi SSL Handshake Protocol đã hoàn tất, dữ liệu ứng dụng có thể được gửi và được
nhận bằng cách sử dụng SSL Record Protocol và các tham số bảo mật được thương lượng và

các thành phần thông tin trạng thái.
III - SSL Record Protocol:
SSL Record Protocol nhận dữ liệu từ các giao thức con SSL lớp cao hơn và xử lý việc phân
đoạn, nén, xác thực và mã hóa dữ liệu. Chính xác hơn, giao thức này lấy một khối dữ liệu có
kích cỡ tùy ý làm dữ liệu nhập và tọa một loạt các đoạn dữ liệu SSL làm dữ liệu xuất (hoặc còn
được gọi là các bản ghi) nhỏ hơn hoặc bằng 16,383 byte.

9


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

hình 1.5: Các bước SSL Record Protocol.

Các bước khác nhau của SSL Record Protocol vốn đi từ một đoạn dữ liệu thô đến một bản ghi
SSL Plaintext (bước phân đoạn), SSL Compressed (bước nén) và SSL Ciphertext (bước mã hóa)
được minh họa trong hình 1.5. Sau cùng, mỗi bản ghi SSL chứa các trường thông tin sau đây:
- Loại nội dung;
- Số phiên bản của giao thức;
- Chiều dài;
- Tải trọng dữ liệu (được nén và được mã hóa tùy ý);
- MAC.
Loại nội dung xác định giao thức lớp cao hơn vốn phải được sử dụng để sau đó xử lý tải
trọng dữ liệu bản ghi SSL (sau khi giải nén và giải mã hóa thích hợp).
Số phiên bản của giao thức xác định phiên bản SSL đang sử dụng (thường là version 3.0)
10


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH

Thiết bị mạng & quản trị mạng

Mỗi tải trọng dữ liệu bản ghi SSL được nén và được mã hóa theo phương thức nén hiện
hành và thông số mật mã được xác định cho session SSL.
Lúc bắt đầu mỗi session SSL, phương pháp nén và thông số mật mã thường được xác định
là rỗng. Cả hai được xác lập trong suốt quá trình thực thi ban đầu SSL Handshake Protocol.
Sau cùng, MAC được thêm vào mỗi bản ghi SSL. Nó cung cấp các dịch vụ xác thực nguồn gốc
thông báo và tính toàn vẹn dữ liệu. Tương tự như thuật toán mã hóa, thuật toán vốn được sử
dụng để tính và xác nhận MAC được xác định trong thông số mật mã của trạng thái session
hiện hành. Theo mặc định, SSL Record Protocol sử dụng một cấu trúc MAC vốn tương tự
nhưng vẫn khác với cấu trúc HMAC hơn. Có ba điểm khác biệt chính giữa cấu trúc SSL MAC và
cấu trúc HMAC:
1. Cấu trúc SSL MAC có một số chuỗi trong thông báo trước khi hash để ngăn các hình thức
tấn công xem lại riêng biệt.
2. Cấu trúc SSL MAC có chiều dài bản ghi.
3. Cấu trúc SSL MAC sử dụng các toán tử ghép, trong khi cấu trúc MAC sử dụng moduloe cộng
2.
Tất cả những điểm khác biệt này hiện hữu chủ yếu vì cấu trúc SSL MAC được sử dụng trước
cấu trúc HMAC trong hầu như tất cả thông số kỹ thuật giao thức bảo mật Internet. Cấu trúc
HMAC cũng được sử dụng cho thông số kỹ thuật giao thức TLS gần đây hơn.
Như được minh họa trong hình 1.5, một số giao thức con SSL được xếp lớp trên SSL Record
Protocol. Mỗi giao thức con có thể tham chiếu đến các loại thông báo cụ thể vốn được gửi
bằng cách sử dụng SSL Record Protocol. Thông số kỹ thuật SSL 3.0 xác định ba giao thức SSL
sau đây:
- Alert Protocol;
- Handshake Protocol;
- ChangeCipherSpec Protocol;
Tóm lại, SSL Alert Protocol được sử dụng để chuyển các cảnh báo thông qua SSL Record
Protocol. Mỗi cảnh báo gồm 2 phần, một mức cảnh báo và một mô tả cảnh báo.
SSL Handshake Protocol là giao thức con SSL chính được sử dụng để hỗ trợ xác thực client

và server và để trao đổi một khóa session. Do đó SSL Handshake Protocol trình bày tổng quan
và được thảo luận trong phần tiếp theo.
Sau cùng, SSL ChangeCipherSpec Protocol được sử dụng để thay đổi giữa một thông số mật
mã này và một thông số mật mã khác. Mặc dù thông số mật mã thường được thay đổi ở cuối
một sự thiết lập quan hệ SSL, nhưng nó cũng có thể được thay đổi vào bất kỳ thời điểm sau đó.
Ngoài những giao thức con SSL này, một SSL Application Data Protocol được sử dụng để
chuyển trực tiếp dữ liệu ứng dụng đến SSL Record Protocol.
11


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

IV - SSL Handshake Protocol:
SSL Handshake Protocol là giao thức con SSL chính được xếp lớp trên SSL Record Protocol. Kết
quả, các thông báo thiết lập quan hệ SSL được cung cấp cho lớp bản ghi SSL nơi chúng được
bao bọc trong một hoặc nhiều bản ghi SSL vốn được xử lý và được chuyển như được xác định
bởi phương pháp nén và thông số mật mã của session SSL hiện hành và các khóa mật mã của
nối kết SSL tương ứng. Mục đích của SSL Handshake Protocol là yêu cầu một client và server
thiết lập và duy trì thông tin trạng thái vốn được sử dụng để bảo vệ các cuộc liên lạc. Cụ thể
hơn, giao thức phải yêu cầu client và server chấp thuận một phiên bản giao thức SSL chung,
chọn phương thức nén và thông số mật mã, tùy ý xác thực nhau và tạo một khóa mật chính
mà từ đó các khóa session khác nhau dành cho việc xác thực và mã hóa thông báo có thể được
dẫn xuất từ đó.
Tóm lại, việc thực thi SSL Handshake Protocol giữa một client C và một server S có thể được
tóm tắt như sau (các thông báo được đặt trong các dấu ngoặc vuông thì tùy ý):
1: C -> S: CLIENTHELLO
2: S -> C: SERVERHELLO
[CERTIFICATE]
[SERVERKEYEXCHANGE]

[CERTIFICATEREQUEST]
SERVERHELLODONE
3: C -> [CERTIFICATE]
CLIENTKEYEXCHANGE
[CERTIFICATEVERIFY]
CHANGECIPHERSPEC
FINISHED
4: S -> C: CHANGECIPHERSPEC
FINISHED
Khi Client C muốn kết nối với server S, nó thiết lập một nối kết TCP với cổng HTTPS (vốn
không được đưa vào phần mô tả giao thức) và gởi một thông báo CLIENTHELLO đến server ở
bước 1 của sự thực thi SSL Handshake Protocol. Client cũng có thể gởi một thông báo
CLIENTHELLO nhằm phản hồi lại một thông báo HELLOREQUEST hoặc chủ động thương
lượng lại các tham số bảo mật của một nối kết hiện có. Thông báo CLIENTHELLO bao gồm các
trường sau đây:
- Số của phiên bản SSL cao nhất được biểu hiện bởi client (thường là 3.0).
- Một cấu trúc ngẫu nhiên do client tạo ra gồm một tem thời gian 32 bit có dạng UNIX chuẩn
và một giá trị 28 byte được tạo ra bởi một bộ tạo số giả ngẫu nhiên.
- Một định danh session mà client muốn sử dụng cho nối kết này.
- Một danh sách các bộ mật mã client hỗ trợ.
- Một danh sách các phương pháp nén mà client hỗ trợ.
Chú ý rằng trường session identity (định danh session) nên rỗng nếu session SSL hiện không
tồn tại hoặc nếu client muốn tạo các tham số bảo mật mới. Ở một trong hai trường hợp, một
trường session identity không rỗng là xác định một session SSL hiện có giữa client và server
(nghĩa là một session có các tham số bảo mật mà client muốn sử dụng lại.). Định danh session
có thể bắt nguồn từ một nối kết trước đó, nối kết này hoặc một nối kết đang hoạt động. Cũng
12


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH

Thiết bị mạng & quản trị mạng

chú ý rằng danh sách các bộ mật mã được hỗ trợ, được chuyển từ client đến server trong
thông báo CLIENTHELLO, chứa các tổ hợp thuật toán mật mã được hỗ trợ bởi client theo thứ
tự ưu tiêm. Mỗi bộ mật mã xác định một thuật toán trao đổi khóa và một thông báo mật mã.
Server sẽ chọn một bộ mật mã hoặc nếu các lựa chọn có thể chấp nhận được không được
trình bầy, trả về một thông báo lỗi và đóng nối kết một cách phù hợp. Sau khi đã gởi thông
báo CLIENTHELLO, client đợi một thông báo SERVERHELLO. Bất kỳ thông báo khác được trả
về bởi server ngoại trừ một thông báo HELLOREQUEST được xem như là một lỗi vào thời
điểm này.
Ở bước 2, server xử lý thông báo CLIENTHELLO và đáp ứng bằng một thông báo lỗi hoặc
thông báo SERVERHELLO. Tương tự như thông báo CLIENTHELLO, thông báo SERVERHELLO
có các trường sau đây:
- Một số phiên bản server chứa phiên bản thấp hơn của phiên bản được đề nghị bởi client
trong thông báo CLIENTHELLO và được hỗ trợ cao nhất bởi Server.
- Một cấu trúc ngẫu nhiên do server tạo ra cũng gồm một tem thời gian 32bit có dạng UNIX
chuẩn và một giá trị 28bit được tạo ra bởi một bộ tạo số ngẫu nhiên.
- Một định danh session tương ứng với nối kết này.
- Một bộ mật mã được chọn từ bởi server từ danh sách các bộ mật mã được hỗ trợ bởi client.
- Một phương pháp nén được chọn bởi server từ danh sách các thuật toán nén được hỗ trợ
bởi client.
Nếu định danh session trong thông báo CLIENTHELLO không rỗng, server tìm trong cache
session của nó nhằm tìm ra một mục tương hợp. Nếu mục tương hợp được tìm thấy và server
muốn thiết lập nối kết mới bằng cách sử dụng trạng thái session tương ứng, server đáp ứng
bằng cùng một giá trị như được cung cấp bởi client. Chỉ địn này là một session được tiếp tục
lại và xác định rằng cả hai phía phải tiến hành trực tiếp với các thông báo
CHANGECIPHERSPEC và FINISHED được trình bày thêm bên dưới. Nếu không, trường này
chứa một giá trị khác nhận biết một session mới. Server cũng có thể trả về một trường định
danh session rỗng để biểu thị rằng session sẽ không được lưu trữ và do đó không thể được
tiếp tục sau đó. Cũng chú ý rằng trong thông báo SERVERHELLO, server chọn một bộ mật mã

và một phương pháp nén từ các danh sách được cung cấp bởi client trong thông báo
CLIENTHELLO. Các thuật toán trao đổi khóa, xác thực, mã hóa và xác thực thông báo được
xác định bởi bộ mã được chọn bởi server và được làm lộ ra trong thông báo SERVERHELLO.
Các bộ mật mã vốn đã được xác định trong giao thức SSL về cơ bản giống như bộ mật mã đã
xác định cho TLS (như được tóm tắt ở các bản 1.4 đến 1.7 trong những bài viết trước).
Ngoài thông báo SERVERHELLO, server cũng phải gởi các thông báo khác đến client. Ví dụ,
nếu server sử dụng sự xác thức dựa vào chứng nhân, server gởi chứng nhận site của nó đến
client trong một thông báo CERTIFICATE tương ứng. Chứng nhận phải thích hợp cho thuật
toán trao đổi khóa của bộ mật mã được chọn và thường là một chứng nhận X.509v3. Cùng
loại thông báo sẽ được sử dụng sau đó cho sự đáp ứng của client đối với thông báo sẽ được sử
dụng sau đó cho sự đáp ứng của client đối với thông báo CERTIFICATERequest của server.
Trong trường hợp của các chứng nhận X.509v3, một chứng nhận có thể thực sự tham chiếu
đến toàn bộ một chuỗi các chứng nhận, được sắp xếp theo thứ tự với chứng nhận của đối
tượng gởi trước tiên theo sau là bất kỳ chứng nhận CA tiến hành theo trình tự hướng đến một
13


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

CA gốc (vốn sẽ được chấp nhận bởi client).
Tiếp theo, server có thể gởi một thông báo SERVERKEYEXCHANGE đến client nếu nó không có
chứng nhận, một chứng nhận vốn có thể được sử dụng chỉ để xác nhận các chữ ký kỹ thuật số
hoặc sử dụng thuật toán trao đổi khóa dựa vào token FORITEZZA (KEA). Rõ ràng, thông báo
này không được yêu cầu nếu chứng nhận site gồm một khóa chung RSA vốn có thể được sử
dụng trong việc mã hóa. Ngoài ra, một server không nặc danh có thể tùy ý yêu cầu một chứng
nhận cá nhân để xác thực client. Do đó, nó gởi một thông báo CERTIFICATERequest đến client.
Thông báo này chứa một danh sách các loại chứng nhận được yêu cầu, được phân loại theo
thứ tự ưu tiên của server cũng như một danh sách các tên được phân biệt cho các CA có thể
chấp nhận. Ở cuối bước 2, server gởi một thông báo SERVERHELLODone đến client để chỉ

định sự kết thúc SERVERHELLO và các thông báo đi kèm.
Sau khi nhận SERVERHELLO và các thông báo đi kèm, client xác nhận rằng chứng nhận site
server (nếu được cung cấp) là hợp lệ và kiểm tra nhằm bảo đảm rằng các thông số bảo mật
được cung cấp trong thông báo SERVERHELLO có thể được chấp nhận. Nếu server yêu cầu sự
xác thực client, client gởi một thông báo CERTIFICATE vốn chứa một chứng nhận cá nhân cho
khóa chung của người dùng đến server ở bước 3. Tiếp theo, client gởi một thông báo
CLIENTKEYEXCHANGE có dạng phụ thuộc vào thuật toán cho mỗi khóa được chọn bởi server:
- Nếu RSA được sử dụng cho việc xác thực server và trao đổi khóa, client tạo một khóa mật
tiền chính 48 byte, mã hóa nó bằng khóa chung được tìm thấy trong chứng nhận site hoặc
khóa RSA tạm thời từ thông báo SERVERKEYEXCHANGE và gởi kết quả trở về server trong
thông báo CLIENTKEYEXCHANGE. Lần lượt server sử dụng khóa riêng tương ứng để giải mã
khóa mật chính.
- Nếu các token FORTEZZA được sử dụng để trao đổi khóa, client dẫn xuất một khóa mã hóa
token (TEK) bằng cách sử dụng KEA. Phép tình KEA cảu client sử dụng khóa chung từ chứng
nhận server cùng với một số tham số riêng trong token của client. Client gởi các tham số
chung cần thiết cho server để cũng tạo TEK, sử dụng các tham sô riêng của nó. Nó tạo một
khóa mật chính, bao bọc nó bằng cách sử dụng TEK và gởi kết quả cùng với một số vector
khởi tạo đến server như là một phần của thông báo CLIENTKEYEXCHANGE. Lần lượt, server
có thể giải mã khóa mật chính một cách thích hợp. Thuật toán trao đổi khóa này không được
sử dụng rộng rãi.
Nếu sự xác thực client được yêu cầu, client cũng gởi một thông báo CERTIFICATEVERIFY đến
server. Thông báo này được sử dụng để cung cấp sự xác thực rõ ràng định danh của người
dùng dựa vào chứng nhận các nhân. Nó chỉ được gởi theo sau một chứng chỉ client vốn có khả
năng tạo chữ ký (tất cả chứng nhận ngoại trừ các chứng nhận chứa các tham số DiffeHallman
cố định). Sau cùng, client hoàn tất bước 3 bằng cách gởi một thông báo CHANGECIPHERSPEC
và một thông báo FINISHED tương ứng đến server. Thông báo FINISHED luôn được gởi ngay
lập tức sau thông báo CHANGECIPERSPEC để xác nhận rằng các tiến trình trao đổi khóa và
xác thực đã thành công. Thực tế, thông báo FINISHED là thông báo đầu tiên vốn được bảo vệ
bằng các thuật toán mới được thương lượng và các khóa session. Nó chỉ có thể được tạo và
được xác nhận nếu những khóa này được cài đặt một cách phù hợp ở cả hai phía. Không đòi

hỏi sự báo nhận thông báo FINISHED; các phía có thể bắt đầu gởi dữ liệu được mã hóa ngay
lập tức sau khi đã gởi thông báo FINISHED. Việc thực thi SSL Handshake Protocol hoàn tất
14


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

bằng việc cũng yêu cầu server gởi một thông báo CHANGECIPHERSPEC và một thông báo
FINISHED tương ứng đến client ở bước 4.
Sau khi sự thiết lập SSL hoàn tất, một nối kết an toàn được thiết lập giữa client và server. Nối
kết này bây giờ có thể được sử dụng để gởi dữ liệu ứng dụng vốn được bao bọc bởi SSL
Record Protocol. Chính xác hơn, dữ liệu ứng dụng có thể được phân đoạn, được nén, hoặc
được mã hóa và đước xác thực theo SSL Record Protocol cũng như thông tin trạng thái
session và nối kết vốn bây giờ được thiết lập (tùy thuộc việc thực thi SSL Handshake Protocol).
SSL Handshake Protocol có thể được rutst ngắn nếu client và server quyết định tiếp tục lại
một session SSL được thiết lập trước đó (và vẫn được lưu trữ) hoặc lặp lại một session SSL
hiện có. Trong trường hợp này, chỉ ba dòng thông báo và tổng cộng sáu thông báo được yêu
cầu. Các dòng thông báo tương ứng có thể được tóm tắt như sau:
1: C -> S: CLIENTHELLO
2: S -> C: SERVERHELLO
CHANECIPHERSPEC
FINISHED
3: S ->C: CHANGECIPHERSPEC
FINISHED
Ở bước 1, client gởi một thông báo CLIENTHELLO đến server vốn có một định danh session
cần được tiếp tục lại. Lần lượt server kiểm tra cache session của nó để tìm một mục tương
hợp. Nếu một mục tương hợp được tìm thấy, server muốn tiếp tục lại nối kết bên dưới trạng
thái session đã xác định, nó trả về một thông báo SERVERHELLO với cùng một định danh
session ở bước 2. Vào thời điểm này, cả client lẫn server phải gởi các thông báo

CHANGECIPHERSPEC và FINISHED đến nhau ở bước 2 và 3. Một khi việc tái thiết lập session
hoàn tất, client và server có thể bắt đầu trao đổi dữ liệu ứng dung.
V - 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.
15


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạ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.
1.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
16


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

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á.
2.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:
 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.
 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.
 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.
 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.
 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.
 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.
 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.
 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”.
17


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

 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”.
 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
VI - Phân tích bảo mật:
Sự phân tích bảo mật toàn diện về SSL 3.0 đã được thực hiện bởi Bruce Scheneier và David
Wagner vào năm 1996. Ngoại trừ một số khiếm khuyết nhỏ và những tính năng gây lo lắng

vốn có thể được sữa chữa dễ dàng mà không cần tu sửa cấu trúc cơ bản của giao thức SSL, họ
không tìm thấy vấn đề điểm yếu hoặc bảo mật nghiêm trọng trong việc phân tích của họ. Kết
quả, họ kết luận rằng giao thức SSL cung cấp sự bảo mật hoàn hảo ngăn việc nghe lén và
những cuộc tấn công thụ động khác, và người thực thi giao thức này sẽ ý thức đến một số
cuộc tấn công chủ động tinh vi.
Tuy nhiên, một vài tháng sau, Daniel Bleichenbacher từ Bell Laboratoires đã tìm thấy một
cuộc tấn công text mật mã được chọn thích ứng nhắm các giao thức dựa vào tiêu chuẩn mà
khóa chung (PKCS) #1. Cuộc tấn công đã được xuất bản vào năm 1998. Tóm lại, một hoạt
động khóa riêng RSA (một hoạt động giải mã hoặc chữ ký kỹ thuật số có thể được thực hiện
nếu kẻ tấn công truy cập một oracle mà đối với bất kỳ text mật mã được chon, trả về chỉ 1 bit
cho biết text mật mã có tương ứng với một số khối dữ liệu không được biết được mã hóa bằng
cách sử dụng PKCS #1 hay không.)
Để tìm hiểu cuộc tấn công Bleichenbacher, cần phải xem PKCS #1. Thực tế, có ba dạng khối
được xác định trong PKCS #1: các loại khối 0 và 1 được sử dụng cho các chữ ký kỹ thuật số
RSA và loại khối 2 được sử dụng cho việc mã hóa RSA. Các phần thảo luận trước, hãy nhớ
rằng nếu thuật toán RSA được sử dụng cho việc xác thực server và trao đổi khóa, client tạo
ngẫu nhiên một khóa mật chính 46 byte, thêm tiền tố hai byte 03 (số phiên bản giao thức SSL)
và 00 vào khóa mật chính, mã hóa kết quả bằng cách sử dụng khóa chung của server và gởi
nó trong một thông báo CLIENTKEYEXCHANGE đến server. Do đó, thông báo
CLIENTkEYEXCHANGE mang khóa mật chính được mã hóa phải phù hợp với dạng được xác
định trong loại khóa 2 PKCS #1.
Bây giờ giả sử có một kẻ tấn công có thể gửi một số tùy ý của các thông báo ngẫu nhiên đến
một server SSL và server đáp ứng cho từng thông báo này bằng 1 bit chỉ định xem một thông
báo cụ thể có được mã hóa chính xác và được mã hóa theo PKCL #1 (do đó server có chức
năng như một oracle hay không). Với sự giả định này, Bleichenbacher đã phát triển một cuộc
tấn công để thực hiện một hoạt động RSA một cách bất hợp pháp với khóa riêng của server
(với một hoạt động giải hoặc một chữ ký kỹ thuật số). Khi được áp dụng để giải mã một khóa
mật chính của thông báo CLIENTKEYEXCHANGE được gửi trước đó, kẻ tấn công có thể tạo lại
khóa mật chính và khóa session vốn được dẫn xuất từ nó một cách phù hợp. Kết quả, sau đó kẻ
tấn công có thể giải mã toàn bộ session (nếu người này đã giám sát và lưu trữ dòng dữ liệu

18


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

của session đó).
Nếu cuộc tấn công có sức chú ý về mặt lý thuyết. Chú ý rằng kết quả thử nghiệm đã cho thấy
thường giữa 300.000 và 2 triệu text mật mã được chọn được yêu cầu để thực sự thực hiện
hoạt động (giải mã hoặc chữ ký kỹ thuật số). Để làm cho mọi thứ trở nên tệ hơn, cuộc tấn
công có thể được thực hiện trên một server SSL vốn có sẵn on-line (vì nó phải hoạt động như
một oracle). Từ quan điểm của kẻ tấn công, có thể khó gửi số lượng lớn text mật mã được
chọn này đến server SSL mà không làm cho nhà quản trị server trở lên nghi ngờ.
Có một số khả năng để ngăn ngừa sự tấn công Bleichenbacher. Trên hết, server không cần đáp
ứng lại một thông báo lỗi sau khi đã nhận một thông báo CLIENTKEYEXCHANGE vốn không
phù hợp với PKCS #1. Một khả năng khác là thay đổi dạng khối PKCS #1 để mã hóa và loại bỏ
các byte 00 và 02 dẫn đầu cũng như các byte 00, 03 và 00 ở giữa thông báo (như được minh
họa trong hình 6.3). Sau cùng, một khả năng khác là sử dụng các sơ đồ mã hóa có khả năng
nhận biết text thuần túy chẳng hạn như các sơ đồ được đề xuất bởi Mihir Bellar và Philip
Rogaway và bất kỳ hệ thống mật mã khóa chng khác vốn có thể bảo vệ ngăn ngừa các cuộc
tấn công text mật mã được chọn thích ứng.

TRIỂN KHAI HTTPS CHO WEBSERVER
HTTP (Hypertext Transfer Protocol) port 80, SMTP (Simple Mail Transfer Protocol)
port 25, POP3 (Post Office Protocol version 3) port 110 là các protocol rất phổ biến
hiện nay. Nhưng trong môi trường Network thì chúng chưa thật sự an toàn vì có thể sniffer
để lấy password. vì thế ta nên triển khai HTTPS (port 443), SMTPS (port 465), POPS
(port 995). Sự khác biệt giữ HTTP, SMTP, POP và HTTPS, SMTPS, POPS là HTTPS, SMTPS,
POPS cung cấp việc mã hóa dữ liệu của user và server, việc mã hóa được thông qua việc sử
dụng giao thức SSL ( Secure Socket Layer) nhằm đảm bảo an toàn thông tin và tránh bị

Sniffer.
Chuẩn bị :
1 Máy đã lên DC, cài đặt sẵn IIS
Bài viết gồm 3 bước :
1/ Cài đặt CA.
2/ Cấu hình IIS xin Certificate.
3/ Kiểm tra kết quả.
Thao tác :
1/ Cài đặt CA.
Vào Start -> Settings -> Control Panel -> Add or Remove Programs -> Windows
Component Wizard -> Check vào Certificate Services.

19


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

Chọn Yes khi gặp popup Microsoft Certificate Services

Nhấn Next tiếp tục.
Trong cữa sổ CA Type chọn Enterprise root CA, chọn Next.

20


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

Trong cữa sổ CA Indentifying Information :

+ Comon name for this CA : Power
+ Validity period : 5 (hoặc số năm tùy ý cả bạn)
+ Các giá trị khác để mặc định.
Next tới

21


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

Trong cữa sổ Cerificate Database Settings để giá trị mặc định. Next tới.

22


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng
Khi gặp Popup hỏi bạn có muốn tắt dịch vụ IIS trong quá trình cài đặt hay không, chọn YES

Tiến trình cài đặt CA bắt đầu.

Chọn Yes để khởi động lại IIS.

Nhấn Finish để hoàn tất quá trình cài đặt.

23


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH

Thiết bị mạng & quản trị mạng
2/ Cấu hình IIS xin Certificate.
Start -> Programs -> Administrative Tools -> IIS Manager
IIS Manager -> PCX -> Web Sites -> Default Web Site
Properties Default Website

Trong cửa sổ Default Web Site, chọn Tab Directory Security, chọn Server Certificate

24


TRƯỜNG CAO ĐẲNG KINH TẾ - CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH
Thiết bị mạng & quản trị mạng

Cửa sổ Wizard xuất hiện, chọn Next

25