Tìm hiểu tấn công CRIME lên giao thức SSLTLS và giải pháp phòng chống.

BAN CƠ YẾU CHÍNH PHỦ
HỌC VIỆN KỸ THUẬT MẬT MÃ

BÁO CÁO BÀI TẬP LỚN

Tìm hiểu tấn công CRIME lên giao thức
SSL/TLS và giải pháp phòng chống.

Các thành viên:

Bùi Thị Thu Giang
Nguyễn Thị Hồng Vân
Nguyễn Đức Duy
Hoàng Hữu Cương

Lớp:

AT9A

Giảng viên hướng dẫn:

Đỗ Quang Trung

Hà Nội, tháng 06 năm 2016


Mục lục


Danh mục từ viết tắt

Tên viết tắt
3-DES
AES
CA
DES
HTTP
HTTPS
MAC
PCT
SSL
TLS

Giải thích ý nghĩa
Triple DES
Advanced Encryption Standard
certificate authority
Data Encryption Standard
HyperText Transfer Protocol
HTTP Secure
Medium Access Control
Private Communication Technology
Secure Sockets Layer
Transport Layer Security


Danh mục các bảng

Danh mục hình vẽ

Hình 2. 1 Cấu trúc của SSL và giao thức SSL
Hình 2. 2 Hình minh họa quá trình trao đổi thông tin
Hình 2. 3 Các bước SSL Record Protocol.
Hình 2. 4 Minh họa 1 đoạn thông điệp chứa thông tin về khóa và quy định thuật
toán


Lời nói đầu
Sercure Socket Layer (SSL) hiện nay là giao thức bảo mật rất phổ biến trên
Internet và đặc biệt là trong các hoạt động thương mại điện tử (E-Commerce).
Việt Nam đang trên đường hội nhập với nền công nghệ thông tin thế giới, nên
nay mai, các hoạt động giao dịch trên mạng ở Việt Nam cũng sẽ diễn ra sôi nổi,
khi đó vấn đề bảo mật trở nên quan trọng, việc triển khai SSL là điều thiết yếu.
Nhận thức được tầm quan trọng đó, nhóm chúng em làm báo cáo này để trình
bày về SSL và tấn công CRIME lên giao thức SSL/TLS. Do lượng kiến thức có
hạn nên không tránh khỏi sai sót.
Mong thầy xem và đóng góp ý kiến cho bài báo cáo cũng như những tìm hiểu
của chúng em được trọn vẹn.


Chương 1: Tìm hiểu Giao thức SSL/TLS
1.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 đối với các
thông tin trên đường truyền. Kể cả người sử dụng lẫn Web server đều không 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 nội dung 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.

7


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á khóa 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 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á khóa 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).
1.2 . TLS là gì?

Transport Layer Security (TLS) là sự kế thừa của Secure Sockets Layer
(SSL), phổ biến nhất và được sử dụng rộng rãi trong các ứng dụng của mật mã
học thực tế trên thế giới. Việc phổ biến sử dụng là để đảm bảo cho các phiên

8


trình duyệt web, nhưng nó cũng có các nhiệm vụ khác, chẳng hạn như bảo vệ
các máy chủ email hay bất kỳ loại giao dịch client-server.
TLS cũng có thể được sử dụng để cung cấp xác thực và mã hóa của Session
Initiation Protocol (SIP). SSL / TLS có thể được sử dụng để cung cấp xác thực
mạnh mẽ của cả hai bên trong một phiên truyền thông, mã hóa mạnh mẽ của dữ
liệu trong chuyển tiếp giữa chúng, và đảm bảo tính toàn vẹn của dữ liệu trong
chuyển tiếp. Trong vài năm qua, các cuộc tấn công khác nhau đã được thiết kế
để tận dụng lợi thế tính chọn lựa của SSL / TLS. Thiết kế của các bộ mã hoá
được sử dụng trong SSL / TLS để mã hóa và tạo khóa.

9


Chương 2: Cấu trúc và cách hoạt động của SSL
2.1. 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
2.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 trên một dịch vụ vận chuyển định hướng
kết nối 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 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 trên TCP một cách trong suốt. Hình 2.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 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, SSL có một định hướng clientserver mạnh mẽ và không đáp ứng các yêu cầu của các giao thức ứng dụng
ngang hàng.

10


Hình 2. 1 Cấu trúc của SSL và giao thức SSL

Tóm lại, giao thức SSL cung cấp sự bảo mật truyền thông vốn có gồm 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ì kết nối được mã hóa trong
suốt sau khi sự thiết lập quan hệ ban đầu và trao đổi khóa phiên đã 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 đang tương
11


tác, các loại dịch vụ đang được sử dụng, và đôi khi dành được 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 TCP SYN hoặc đoạt phiên làm việc .
Để sử dụng sự bảo vệ của 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 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 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 hạn như SSL trong suốt giai đoạn thiết lập kết nối 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 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, việc sử dụng các 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 kết nối 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) thêm sự hỗ trợ xác thực vào các giao thức
12


ứ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 cho một giao thức ứng
dụng đã biết.
Các 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 2.1 và được minh họa một phần trong hình
2.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ảng 2. 1 Các cổng được gán cho các giao thức ứng dụng chạy trên TLS/SSL.
Từ khóa

Cổng

Mô tả

Nsiiop

261

Dịch vụ tên IIOP trên TLS/SSL

https

443

HTTP trên TLS/SSl

Smtps

465

SMTP trên TLS/SSL

Nntps

563

NNTP trên TLS/SSL

Ldaps

636

LDAP trên TLS/SSL

Ftps-data

989

FTP (dữ liệu) trên TLS/SSL

Ftps

990

FTP (Điều khiển) trên TLS/SSL

Tenets

992

TELNET trên TLS/SSL

Imaps

994

IRC trên TLS/SSL

Pop3s

995

POP3 trên TLS/SSL

Nói chung, một phiên 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 phiên. Các phần tử thông tin
trạng thái phiên 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 chính bí mật và
một cờ chỉ định việc phiên có thể tiếp tục lại hay không. Một phiên SSL có thể
13


đượ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. 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 cho server và client, các khóa
cho 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 phiên
SSL đồng thời và các phiên có nhiều nối kết đồng thời.

14


Bảng 2. 2 Các thành phần thông tin trạng thái phiên SSL
Thành Phần

Mô tả

Session ID

Định danh được chọn bởi server để nhận dạng một
trạng thái phiên hoạt động hoặc có thể tiếp tục lại.

Peer certificate

Chứng nhận X.509 phiên bản 3 của thực thể ngang
hàng.

Compression
method

Thuật toán dùng để nén dữ liệu trước khi mã hóa

Cipher spec

Thông số của các thuật toán mã hóa dữ liệu và MAC

Master secret

Khóa bí mật 48-byte được chia sẻ giữa client và server.

Is resumable

Cờ biểu thị phiên có thể được sử dụng để bắt đầu các
nối kết mới hay không.

Bảng 2. 3 Các thành phần thông tin trạng thái nối kết SSL
Thành Phần

Mô tả

Server và client
ngẫu nhiên

Các chuỗi byte được chọn bởi server và client cho mỗi

nối kết.

Khóa bí mật
MAC cho
server

Khóa bí mật được sử dụng cho các hoạt động MAC trên
dữ liệu được tạo bởi server.

Khóa bí mật
Khóa bí mật được sử dụng cho các hoạt động MAC trên
MAC cho client dữ liệu được tạo bởi client.

15


Khóa cho
server

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 cho client Khóa được sử dụng để mã khóa dữ liệu bởi client và giải
mã bởi server.
Initialization
vector

Trạng thái khởi tạo cho một mã hóa khối trong chế độ
CBC. Trường này được khởi tạo đầu tiên bởi SSL
Handshake Player. Sau đó, khối văn bản mã hóa sau

cùng từ mỗi bản ghi được dành riêng để sử dụng vởi bản
ghi sau đó.

Số chuỗi

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 kết nối
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, bí mật dữ liệu và dữ liệu.
- Các dịch vụ toàn vẹn.
- 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ý phiên SSL và thiết lập kết nối.
Giao thức con SSL quan trọng nhất là SSL Handshake Protocol. Giao thức
này là một giao thức xác thực và trao đổi khóa 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 phiên hoặc kết nối SSL.
Sau khi SSL Handshake Protocol đã hoàn tất, dữ liệu ứng dụng có thể được
16


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. SSL Record và
Handshake Protocol được trình bày tổng quan ở phần tiếp theo.
2.2. 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,
được xử lý và được chuyển, được xác định bởi phương pháp nén và thông số
mật mã của phiên SSL hiện hành và các khóa mật mã của kết nối 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ã, xác thực lẫn
nhau và tạo một khóa chính bí mật mà từ đó các khóa phiên 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]

17


CLIENTKEYEXCHANGE
[CERTIFICATEVERIFY]
CHANGECIPHERSPEC
FINISHED
4: S -> C: CHANGECIPHERSPEC
FINISHED

Hình 2.2 Hình minh họa quá trình trao đổi thông tin

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
18


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
chuẩn UNIX và một giá trị 28 byte được tạo ra bởi một bộ sinh số giả ngẫu
nhiên.
- Một phiên định danh 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 (phiên định danh) nên rỗng nếu phiên 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 xác định một
phiên SSL hiện có giữa client và server (nghĩa là một phiên có các tham số bảo
mật mà client muốn sử dụng lại.). Phiên định danh có thể bắt nguồn từ một nối
kết trước đó, kết nối này hoặc một kết nối đang hoạt động. Cũ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ên. 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

kết nối 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 nà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
19


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 chuẩn UNIX chuẩn và một giá trị 28bit được tạo ra bởi một bộ sinh số
ngẫu nhiên.
- Một phiên định danh tương ứng với kết nối này.
- Một bộ mật mã được chọn 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 trường session identity trong thông báo CLIENTHELLO không rỗng,
server tìm trong cache phiên của nó nhằm tìm ra một mục tương thích. Nếu mục
tương thích được tìm thấy và server muốn thiết lập kết nối mới bằng cách sử
dụng trạng thái phiên tương ứng, server đáp ứng bằng cùng một giá trị như được
cung cấp bởi client. Chỉ định này là một phiên đượ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 phiên mới. Server cũng có thể trả về một trường
session identity rỗng để biểu thị rằng phiên 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.
20


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á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 gốc CA (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ỹ 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 trang 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 trang 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 xác thực client, client gởi một thông
21


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 chính 48 byte, mã hóa nó bằng khóa chung được tìm thấy trong
chứng

nhận

trang

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ủa
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á 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
22

đã 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 phiên. 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 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. Kết nối 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 phiên và kết nối 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 rút ngắn nếu client và server quyết định
tiếp tục lại một phiên SSL được thiết lập trước đó (và vẫn được lưu trữ) hoặc
lặp lại một phiên 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

23

Ở bước 1, client gởi một thông báo CLIENTHELLO đến server có một phiên
định danh cần được tiếp tục lại. Lần lượt server kiểm tra cache phiên của nó để
tìm một mục tương thích. Nếu một mục tương thích được tìm thấy, server muốn
tiếp tục lại kết nối bên dưới trạng thái phiên đã xác định, nó trả về một thông
báo SERVERHELLO với cùng một phiên định danh ở 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 phiên hoàn tất,
client và server có thể bắt đầu trao đổi dữ liệu ứng dụng.

24


2.3. 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ào và tạo một loạt
các đoạn dữ liệu SSL làm dữ liệu xuất ra (hoặc còn được gọi là các bản ghi) nhỏ
hơn hoặc bằng 16,383 byte.
Các bước SSL Record Protocol.

25