Đề tài bảo mật thông tin EXTENSIBLE AUTHENTICATION PROTOCOL TRANSPORT LAYER SECURITY(EAP TLS)

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC KỸ THUẬT CÔNG NGHỆ TP. HCM

ĐỀ TÀI BẢO MẬT THÔNG TIN

EXTENSIBLE AUTHENTICATION PROTOCOL
TRANSPORT LAYER SECURITY
(EAP-TLS)
Khoa:
Chuyên ngành:

Công Nghệ Thông Tin
Mạng Máy Tính

Giảng viên hướng dẫn:
Nhóm Sinh viên thực hiện:
Mã Chí Trung
Mssv: 1191020168
Phạm Minh Trung
Mssv: 1191020164
Phạm Gia Đông
Mssv: 1191020017
Trịnh Hưng Hưng
Mssv: 1191020039
Võ Thanh Tâm
Mssv: 1191020120
Trịnh Đăng Tuấn
Mssv: 1191020175

Th.S Văn Thiên Hoàng

Lớp: 11HTHM1
Lớp: 11HTHM1
Lớp: 11HTHM1
Lớp: 11HTHM1
Lớp: 11HTHM1
Lớp: 11HTHM1

TP. Hồ Chí Minh, 2012

1


CHƯƠNG I: GIỚI THIỆU TỔNG QUAN EAP-TLS

1.1 EAP-TLS là gì ?
EAP-TLS là chữ viết tắt của Extensible Authentication Protocol – Transport Layer Security
(giao thức thẩm định quyền truy cập có thể mở rộng – bảo mật lớp truyền dẫn). Kết nối dựa
trên giao thức này đòi hỏi có một chứng nhận người sử dụng (user certificate) trên cả máy
khách và máy chủ IAS .

Đây là cơ chế có mức độ an toàn nhất ở cấp độ người sử dụng, nó cho phép một phương
pháp xác thực tùy ý được sử dụng để truyền thông tin ủy nhiệm và trao đổi thông tin có
chiều dài tùy ý.

EAP là một phần mở rộng cho Point-to-point (PPP) và giao thức này được tổ chức IETF
định nghĩa trong cuốn RFC 2284.
Các đặc tính của EAP-TLS bao gồm:
•

Xác thực lẫn nhau (giữa máy chủ và khách hàng) .

•

Trao đổi khoá (để thiết lập WEP động và khoá TKIP) .

•

Phân mảnh và nối lại (với bản tin EAP dài cần có phần kích thước kiểm tra nếu cần) .

•

Kết nối nhanh (thông qua TLS) .

1.1.1 Nhu cầu sử dụng
EAP được tạo nhằm phản hồi lại yêu cầu về những phương pháp xác thực mạnh mẽ hơn,
những phương pháp này sao lưu dự phòng những thiết bị bảo mật bổ sung, chẳng hạn như
các chứng nhận hoặc smart card cũng như các tổ hợp tên người dùng và password chuẩn.
Hiện nay EAP là phương pháp theo tiêu chuẩn công nghiệp để sử dụng với những
phương pháp xác thực bổ sung với PPP.

2


EAP-TLS sử dụng khoá kiểm tra công khai TLS trong EAP để cung cấp việc xác thực lẫn
nhau giữa máy chủ và khách hàng. Với EAP-TLS, cả máy chủ và khách hàng đều phải
đăng ký chữ ký dạng số thông qua quyền chứng thực (CA) để kiểm tra.
EAP cung cấp bảo mật mạnh mẽ bằng cách yêu cầu cả máy chủ lẫn máy khách xác nhận
chứng thực bằng PKI.Các gói tin EAP tương tác với máy khách lẫn máy chủ được mã
hóa và bảo vệ kết nối mạng bằng TLS. Nhược điểm với giao thức này là sử dụng và cài
đặt chứng thực luôn ở cả hai bên.

1.1.2 Giải pháp công nghệ liên quan
Ngày nay các mạng 802.11 xác thực theo chuẩn 802.1x . Chuẩn này xác định giao thức
xác thực mở rộng (EAP) trực tiếp qua lớp kết nối. EAP là giao thức truyền thông được sử
dụng thông qua các loại cơ chế xác thực khác nhau. Các phương pháp EAP phát triển cho
mạng không dây được dựa trên việc kiểm tra thông qua khoá công cộng và giao thức bảo
mật tại lớp truyền dẫn (TLS). Các giao thức đó là EAP-TLS, EAP-TTLS và PEAP.
 EAP-TTLS :

Giao thức chứng thực đường hầm (EAP-TTLS) cung cấp một loạt các thuộc tính
cho một bản tin như RADIUS EAP - dùng tầng vận chuyển, EAP-TTLS có thể
cung cấp các chức năng như phương thức PEAP . Tuy nhiên nếu mật khẩu của
RADIUS hoặc CHAP được mã hoá, thì TTLS có thể bảo vệ được các tính chất kế
thừa của RADIUS. Khi máy chủ TTLS gửi bản tin RADIUS tới máy chủ tại đích,
nó sẽ giải mã các thuộc tính bảo vệ của EAP-TTLS và chèn chúng trực tiếp vào
bản tin chuyển đi. Bởi vì phương thức này giống như PEAP, nên nó ít được sử
dụng hơn.

Hình 1- Giao diện TTLS
 PEAP :

3


Giống như chuẩn TTLS, PEAP tạo khả năng xác thực cho mạng LAN không dây
mà không yêu cầu xác thực. Protected EAP ( PEAP ) thêm lớp TLS lên trên cùng
EAP giống như EAP-TTLS, rồi sau đó sử dụng kết quả của phiên TLS như
phương tiện vận chuyển để bảo vệ phương thức EAP. PEAP sử dụng TLS để xác
thực từ máy chủ tới máy trạm nhưng không có chiều ngược lại. Theo phương thức
này chỉ máy chủ yêu cầu khoá xác thực còn khách hàng thì không. Máy chủ và

máy trạm trao đổi chuỗi thông tin mã hoá trong TLS, và bản tin TLS được xác
thực và mã hoá sử dụng khoá đã được thông qua giữa hai bên.
PEAP cung cấp dịch vụ cho phương thức EAP như sau:
•

Bản tin xác nhận (Những kẻ tấn công sẽ rất khó khăn trong việc chèn vào bản
tin EAP) .

•

Mã hoá bản tin (Những kẻ tấn công sẽ không thể đọc và giải mã bản tin EAP)

•

Xác thực từ máy chủ đến khách hàng (vì thế phương thức này chỉ cần bảo vệ
xác thực từ khách hàng tới máy chủ) .

•

Trao đổi khoá (để thiết lập cho WEP động hoặc khoá TKIP) .

•

Phân mảnh và ghép lại (cần thiết nếu bản tin EAP dài) .

•

Thiết lập kết nối nhanh ( thông qua phiên TLS ) .

1.1.3 Môi trường áp dụng

EAP-TLS thường được sử dụng trong các mô trường doanh nghiệp lớn, tuy nhiên cũng
có thể được sử dụng trong các tổ chức nhỏ hơn.
802.1x là chuẩn đặc tả cho việc truy cập dựa trên cổng (port-based) được định nghĩa bởi
IEEE. Hoạt động trên cả môi trường có dây truyền thống và không dây. Việc điều khiển
truy cập được thực hiện bằng cách: khi một người dùng cố gắng kết nối vào hệ thống
mạng, kết nối của người dùng sẽ được đặt ở trạng thái bị chặn ( blocking ) và chờ cho
việc kiểm tra định danh người dùng hoàn tất.

4


Mô hình xác thực 802.1X-EAP cho Client diễn ra như sau:

5


Hình 2- Quá trình trao đổi thông tin xác thực của 802.1x

6


1.1.4 Phân loại EAP Packet

Type

Description

1–6

Assigned by RFC

1

Identity

2

Notification

3

Nak (response only)

4

MD5-Challenge

5

One-Time Password (OTP)

6

Generic Token Card (GTC)

7

Not assigned

8

Not assigned

9

RSA Public Key Authentication

10

DSS Unilateral

7


11

KEA

12

KEA-VALIDATE

13

EAP-TLS

14

Defender Token (AXENT)

15

RSA Security SecurID EAP

16

Arcot Systems EAP

17

EAP-Cisco Wireless (LEAP)

18

Nokia IP SmartCard authentication

19

SRP-SHA1 Part 1

20

SRP-SHA1 Part 2

21

EAP-TTLS

22

Remote Access Service

23

UMTS Authentication and Key Agreement

8


24

EAP-3Com Wireless

25

PEAP

26

MS-EAP-Authentication

27

Mutual Authentication w/Key Exchange
(MAKE)

28

CRYPTOCard

29

EAP-MSCHAP-V2

30

DynamID

31

Rob EAP

32

SecurID EAP

33

EAP-TLV

34

SentriNET

35

EAP-Actiontec Wireless

36

Cogent Systems Biometrics Authentication EAP

9


37

AirFortress EAP

38

EAP-HTTP Digest

39

SecureSuite EAP

40

DeviceConnect EAP

41

EAP-SPEKE

42

EAP-MOBAC

43

EAP-FAST

44-191

Not assigned; can be assigned by IANA on the
advice of a designated expert

192–253

Reserved; requires standards action

254

Expanded types

255

Experimental usage

1.2 Mô hình kiến trúc và triển khai ứng dụng
802.1x EAP-TLS được sử dụng trong các mô trường cơ bản và an toàn cao. Sự trao đổi
của các message EAP-TLS cung cấp sự xác nhận lẫn nhau, sự bắt tay của giao thức mã
hóa và sự trao đổi khóa bảo vệ giữa một client không dây và mạng EAP-TLS là một kỹ
10


thuật cung cấp các khóa mã hóa động cho người dùng và session. Điều này cải thiện một
cách đáng kể và vượt qua nhiều điểm yếu trong các mạng không dây. Hình dưới đây chỉ
ra một chuỗi các sự kiện xuất hiện khi một Client được xác nhận bằng 802.1x EAP-TLS.

Hai chứng chỉ digital được yêu cầu ở đây: một trên RADIUS server (ví dụ EAS) và một
trên Client không dây. Chú ý rằng sự truy cập không dây được cung cấp cho tới khi sự
xác nhận thành công và các khóa WEP động đã được thiết lập.

Hình 3-Xác nhận 802.1x EAP-TLS
802.1x EAP-TLS với EAS trong Controller Mode Client không dây có chứng chỉ điện tử
(digital certificate) được cài đặt từ trước. Mạng nội bộ không dây (WLAN) giao tiếp với
EAS thông qua Access Point (AP). Tất cả ba thành phần (Wireless client, AP và EAS) hỗ
trợ cho quá trình chứng thực 802.1x EAP-TLS.WLAN có thể sử dụng Windows XP (được
xây dựng để hỗ trợ cho 802.1x EAP-TLS hay Windows 98/Me/2000) bằng việc sử dụng
Madge Wireless LAN Utility (WLU). Khi xác nhận, dữ liệu người dùng cũng có thể được
sử dụng EAS mà đã được cấu hình trong Gateway Mode.

11


Hình 4- 802.1x EAP-TLS
trong Controller Mode

CHƯƠNG II: GIAO THỨC EXTENSIBLE AUTHENTICATION
PROTOCOL – TRANSPORT LAYER SECURITY

2.1 Giao thức EAP-TLS:
2.1.1 Sơ đồ hoạt động của EAP-TLS (RFC 5216)

12


Được mô tả trong RFC 5216, cuộc đối thoại sẽ được bắt đầu với bên gửi và bên nhận tiến
hành thương lượng các gói tin EAP.Bên server sẽ gửi một gói tin EAP-Request cho client

yêu cầu xác định danh tính ( Indentify ), sau đó client sẽ phản hồi ngược lại cho server bằng
gói tin EAP-Response chứa User-ID của mình.Kể từ đó cuộc nói chuyện sẽ được bắt đầu
giữa EAP-Server và client.
Một khi đã nhận được Identity của client, EAP-Server phải phản hồi cho client bằng gói tin
EAP-TLS start, đó là một gói EAP-Request với EAP-type=EAP-TLS, cuộc trò chuyện bắt
đầu, bên phía client sẽ gửi một gói tin EAP-Response, type=EAP-TLS.Trường dữ liệu của

13


gói tin sẽ được đóng gói một hoặc nhiều TLS record ở định dạng TLS record layer, chứa
thông điệp bắt tay ( TLS client_hello ).
Client_hello message bao gồm số phiên bản TLS của client ( peer’s TLS version number ),
session ID, một con số phát sinh ngẫu nhiên và bộ mã hoá được hỗ trợ bởi client.Phiên bản
TLS của client phải tương ứng với TLS v1.0 hoặc cao hơn.
EAP-Server sẽ trả lời lại với một gói tin EAP-Request với EAP-type=EAP-TLS, gói tin này
bao gồm TLS server_hello handshake message, server_key_exchange,
certificate_request,server_hello_done.Trong đó server_hello_handshake message gồm TLS
version number , một con số phát sinh ngẫu nhiên khác ( another random number ), session
ID và một bộ mã hoá ( ciphersuite ).
Nếu session ID của client là null hoặc server không thể nhận biết được thì lúc này server sẽ
phải chọn một session ID khác để thiết lập phiên giao dịch mới.Ngược lại nếu session ID mà
server nhận được từ client trùng khớp với session ID client gửi thì phiên giao dịch trước đó
sẽ được bắt đầu lại với session ID này.
Nếu server không bắt đầu lại với phiên giao dịch đã thiết lập trước đó , thì gói tin mà nó gửi
cho client phải bao gồm thông điệp bắt tay ( handshake message) TLS server_certificate và
server_done_hello handshake message phải là thông điệp bắt tay cuối cùng được đóng gói
trong gói tin EAP-Request.
Certificate message chứa một chứng chỉ khoá công khai (public key certificate) hoặc là trao
đổi khoá công khai ( chẳng hạn như RSA hoặc Diffie-Hellman ) hoặc là chữ ký khoá công

khai ( như là RSA hay DSS-Digital Signature Standard ).
Nếu bên phía client hỗ trợ EAP-TLS và được cấu hình để sử dụng giao thức này thì phải
phản hồi gói tin EAP-Request bằng gói tin EAP-Response với type=EAP-TLS.Nếu
server_hello_message trước đó được gửi bởi EAP-Server trong gói tin EAP-Request trước
đó không bắt đầu lại phiên giao dịch trước thì trường dữ liệu của gói tin phải đóng gói bằng
một hoặc nhiều TLS record trong đó chứa TLS client_key_exchange, change_cipher_spec và
finished message.
Nếu EAP-Server gửi một certificate_request_message trong gói EAP-Request trước đó, trừ
khi client được cấu hình riêng thì client phải gửi bổ sung certificate và
certificate_verify_message.EAP-Server sẽ xác nhận certificate của client và chữ ký điện tử
nếu server được yêu cầu.
Nếu server_hello_message trước đó được gửi từ server nằm trong gói EAP-Request bắt đầu
lại phiên giao dịch trước thì bên phía client chỉ phải gửi change_cipher_spec và finished_
handshake_message ( chứa client authentication phản hồi lại EAP-Server ).

2.1.1.1

EAP-TLS Packet Format : (RFC 3748)
14


Một EAP-TLS packet có cấu trúc như sau :



Code : code field chiếm 1 octet và nhận dạng các loại gói tin EAP.
Request.
Response.
Success.
Failure.

Identifier: Identifier field chiếm 1 octet và giúp cho Response và Request trùng
khớp với nhau.
1.
2.
3.
4.





Length: chiếm 2 octet , cho biết độ dài của gói tin.Mỗi octet của gói tin EAP bao
gồm Code, Identifier , Length và Data fields.Những octet nào nằm ngoài giá trị
của Length field sẽ bỏ qua.Một message với trường độ dài ( Length Field ) nào
mà thiết lập giá trị lớn hơn số lượng các octet nhận được phải được loại bỏ.



Data: có thể là 0 hoặc chiếm nhiều octet.Định dạng của trường dữ liệu được xác
định bởi Code Field.

2.1.1.2

EAP-TLS Request Packet : (RFC 5216)

Một EAP-TLS Request Packet có cấu trúc như sau:

15



Code : giá trị =1 ( request packet ).



Indentifier : phải được thay đổi trên mỗi Request Packet.



Length : cho biết độ dài của gói tin EAP bao gồm Code, Identifier , Length ,
Type và Data Field.



Type : nhận giá trị=13 –EAP-TLS.



Flags :










L:
M:
S:
R:

Length included
More fragments
EAP-TLS start
Reserved

-Bit L cho biết sự hiện diện của 4 octets TLS message field và được đặt cho phân
đoạn mạng ( fragment ) đầu tiên của fragmented TLS message.
-Bit M : hiển thị tất cả ngoại trừ fragment cuối.
-Bit S : được cài đặt làm EAP-TLS start message, khác biệt với fragment
acknowledgment.
-Bit R : bit dự trữ.
TLS Message Length : chiếm 4 octet , trường này chỉ hiện diện nếu bit L bật
lên.Nó cung cấp tổng chiều dài của TLS Message hoặc bộ message đang được
phân đoạn.
TLS Data : làm nhiệm vụ đóng gói TLS Packet bằng định dạng TLS Record.
16


2.1.1.3

EAP-TLS Response Packet : (RFC 5216)

Có cấu trúc tương tự EAP-TLS Request Packet.



Code : giá trị = 2 ( response packet ).



Identifier : chiếm 1 octet, phải trùng khớp với Identifier form request.



Length : chiếm 2 octet, cho biết độ dài của gói tin EAP bao gồm Code, Identifier,
Length, Type và Data Field.Những byte nào nằm ngoài dãy Lengh Field được
xemm như là lớp độn data link layer và phải được bỏ qua khi tiếp nhận.



Type: nhận giá trị =13-EAP-TLS.



Flags :

 L:
 M:
 R:

Length included
More fragments
Reverved

-Bit L : chiếm 4 octet, cho biết sự hiện diện của trường TLS Message và được đặt

cho phân đoạn ( fragment ) đầu tiên của fragmented TLS message.
-Bit M : gồm tất cả ngoại trừ fragment cuối.
-Bit R : bit dự trữ.

17




TLS Message Length : chiếm 4 octet, chỉ hiện diện nếu bit L bật lên.Trường này
cung cấp tổng chiều dài của TLS Message hoặc bộ message đang được phân
đoạn.



TLS Data : làm nhiệm vụ đóng gói TLS Packet bằng định dạng TLS record.

2.1.1.4

EAP-TLS Success and Failure : (RFC 3748)

Gói tin thành công được gửi từ server đến client sau khi hoàn thành bằng phương
pháp chứng thực EAP ( type = 4 hoặc lớn hơn ) để cho biết rằng client đã chứng
thực thành công bởi server.
Server phải truyền một gói tin EAP với Code = 3 ( success ). Nếu server không
thể chứng thực được client ( không thể chấp nhận phản hồi từ một hay nhiều yêu
cầu ) sau khi chứng thực bằng phương pháp EAP kết thúc không thành công, thì
phải truyển một gói tin EAP bổ sung với Code = 4 ( failure ) .
Success & failure packets không được chứa dữ liệu bổ sung và phải không được
gửi bởi EAP server nếu phương pháp chứng thực không cho phép kết thúc tại thời

điểm đó.

2.1.2

Initial EAP Request / Respones Types (RFC-2284)
2.1.2.1

Identity

Được sử dụng để xác định danh tính của client.Nhà chứng thực sẽ cấp phát
yêu cầu lúc ban đầu.Một thôn g báo được hiển thị them có thể gồm dấu nhắc
lệnh cho client trong trường hợp đang tương tác với người sử dụng.Thông báo
phản hồi phải được gửi cho bên Request với type = 1.
Type: = 1
Type-Data : trường này chưa thông điệp có thể hiển thị bên phản hồi
( Request). Bên phản hồi sử dụng trường này để trả lại Indentity.Nếu Identity
không rõ ràng thì trường này có chiều dài là 0 octet và không được mang giá
trị rỗng ( NULL ). Trường này có chiều dài nhận từ độ dài của gói tin
Request/Response do đó giá trị NULL là không cần thiết.

2.1.2.2

Notification
18


Được tuỳ chọn sử dụng để truyền tải thông tin được hiển thị từ nhà chứng
thực đến với client.Client nên hiển thị thông tin đến với người sử dụng hoặc
đăng nhập vào nếu không thể hiển thị được.
Notification được thiết kế để cung cấp thông báo chấp nhận của 1 số tính chất

bắt buộc.Chẳng hạn như 1 mật khẩu sắp hết hạn thì số thứ tự của mật khẩu đó
gần bằng 0. Hầu hết trong các trường hợp, thông báo trên không được yêu
cầu.
Type: = 2
Type-Data: trường dữ liệu bên Request chứa đúng 1 thông điệp hiển thị có độ
dài lớn hơn 0.Chiều dài của thông điệp này được xác định bởi trường độ dài
( Length Field ) của gói tin Request.Các thông điệp không được mang giá trị
kết thúc là rỗng ( NULL ).Bên phản hồi ( Response) phải được gửi hồi đáp
cho bên yêu cầu ( Request ) tới type = 2 ( notification ).Trường dữ liệu ( datatype ) của bên phản hồi có độ dài là 0 octet và phải được gửi ngay lập tức.

2.1.2.3

Nak

Chỉ có giá trị trong các tin nhắn phản hồi ( response message ).Nó được gửi để
trả lời cho bên Request nơi mà nếu kiểu xác thực không thể chấp nhận
được.Kiểu chứng thực được đánh số thứ tự là 4 và lớn hơn nữa.Bên Response
chứa kiểu chứng thực mà client mong muốn.
Type: =3
Type-Data: phải chứ duy nhất 1 octet để chỉ rõ kiểu chứng thực mong muốn.

2.1.2.4

MD5-Challenge

Tương tự như giao thức PPP CHAP.Bên Request chứa 1 “challenge” message
và gửi cho client, bên Response phải được gửi để trả lời cho bên Resquest và
có thể có loại 4 ( MD5-Challenge ) hoặc loại 3 ( Nak ).Việc triển khai EAP
phải hỗ trợ cơ chế chứng thực MD5-Challenge.
Type : = 4

Type-Data: nội dung của trường dữ liệu này được tóm tắt dưới đây

19


2.1.2.5

One-Time Password (OPT)

Bên yêu cầu ( Request ) chứa một thông điệp hiển thị gồm 1 OPT
Challenge.Bên phía phản hồi ( Response ) phải gửi trả lời cho bên Request và
phải thuộc loại 5 ( OPT ) hoặc 3 ( Nak ).Nak reply cho biết kiểu cơ chế chứng
thực mà client mong muốn.
Type: =5
Type-Data: OPT Challenge là một thông điệp hiển thị của bên Request.Bên
hồi đáp, trường này được sử dụng cho “6 từ” trong “One-Time Password
System” ( RFC-1938 ).Các thông điệp này không được kết thúc bằng giá trị
rỗng ( NULL ).Độ dài của trường này nhận được từ chiều dài của gói tin
Request/Response.

2.1.2.6

Generic Token Card

Được định nghĩa để sử dụng với việc triển khai Token Card khác nhau mà yêu
cầu người sử dụng nhập vào.Bên yêu cầu chứa một tin nhắn dạng văn bản
ASCII và bên trả lời chứa tin nhắn Token Card cần thiết cho việc chứng
thực.Thông tin này được người sủ dụng đọc từ thiết bị Token Card và nhập
như dạng văn bản ASCII.
Type: = 6

Type-Data: trường dữ liệu bên yêu cầu chứa thông điệp để hiển thị có độ dài
lớn hơn 0 octet.Chiều dài của thông điệp này được xác định bởi trường độ dài
( Length Field ) của gói tin Request và không được mang giá trị rỗng
( NULL).Bên phản hồi phải gửi tin nhắn trả lời cho bên yêu cầu với type = 6,
và chứa dữ liệu từ Token Card đòi hỏi việc xác thực.Chiều dài của dữ liệu
được xác định bởi trường dữ liệu của gói tin Response.

2.1.3

TLS Protocol (RFC 4346)

20


TLS Protocol được chia làm hai lớp.Lớp đầu tiên là Handshake Protocol Layer
bao gồm ba giao thức con: Handshake Protocol, Change Cipher Spec Protocol và
Alert Protocol.Lớp thứ hai là Record Protocol Layer.

Record Layer Protocol: giao thức ở lớp này nhận và mã hoá dữ liệu từ lớp ứng
dụng (application layer) và cung cấp cho lớp vận chuyển(Transport layer ).Record
Protocol lấy dữ liệu, phân mảnh nó cho phù hợp với kích thước của thuật toán mã
hoá, áp dụng MAC (Message Authentication code ) hoặc HMAC ( Hash-based
Message Authentication Code ) và sau đó mã hoá hoặc giải mã dữ liệu bằng cách
sử dụng thông tin đã thoả thuận trước trong Handshake Protocol.
Handshake Protocol chịu trách nhiệm cho việc thương lượng phiên giao dịch bao
gồm các hạng mục sau đây :
 Session Identifier: một chuỗi byte tuỳ ý được lựa chọn bởi máy chủ để

xác định trạng thái phiên giao dịch một cách chủ động hoặc có thể khôi
phục lại.

 Peer Certificate: chứng chỉ X509v3 [X509] của client, trạng thái này có

thể là Null.
 Compression method: thuật toán dùng để nén dữ liệu trước khi mã hoá.
 Cipher spec: chỉ định các thuật toán mã hoá dữ liệu số lượng lớn ( vd như

Null , DES … ) và thuật toán MAC ( MD5 hoặc SHA ), ngoài ra nó còn
định nghĩa mã hoá các thuộc tính như kích thước hàm băm ( hash_size ).
 Master secret: 48 byte bí mật được chia sẻ giữa client và server.
21


 Resumable: một lá cờ hiệu cho biết rằng liệu phiên giao dịch có thể được

sử dụng để bắt đầu kết nối mới.

2.1.3.1

Change Cipher Spec Protocol

Là giao thức tồn tại để báo hiệu quá trình chuyển đổi chiến lược mã hoá.Giao
thức gồm một tin nhắn đơn lẻ được mã hoá và nén bằng trạng thái kết nối hiện tại.
Message này gồm 1 byte riêng lẻ có giá trị = 1

struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
Change cipher spec message được gửi cho cả client và server để thông báo cho
bên nhận rằng các bản ghi ( record ) tiếp theo sẽ được bảo vệ bằng CipherSpec
mới nhất và các khoá.Việc tiếp nhận thông điệp (message) này được thực hiện đối

với bên nhận để chỉ cho Record Layer sao chép trạng thái chờ đọc vào trạng thái
đọc hiện hành ngay lập tức.
Sau khi gửi thông điệp này đi, người gửi (sender) phải hướng dẫn cho Record
Layer biết để chuyển sang trạng thái ghi và trạng thái này được kích hoạt.Change
cipher spec message được gửi trong suốt quá trình bắt tay ( handshake ) sau khi
các thông số bảo mật đạt được thoả thuận nhưng trước khi thông điệp xác nhận
kết thúc ( verifying finished message ) được gửi.

Change Cipher Spec Protocol

2.1.3.2

Alert Protocol

Một trong các kiểu nội dung được hỗ trợ bởi phân lớp TLS Record là kiểu báo
động ( Alert Type ). Alert message truyền đạt mức độ nghiêm trọng của tin nhắn
và sự mô tả về cảnh báo. Tin nhắn cảnh báo với kết quả mà gây ra thiệt hại
nghiệm trọng thì kết nối đó sẽ được huỷ ngay lập tức.Trong trường hợp này, các
kết nối khác tương ứng với phiên giao dịch có thể tiến hành tiếp tục nhưng phiên
giao dịch định danh ( session identifier ) phải bị mất hiệu lực và ngăn chặn các
22


phiên không thành công ( fail session ) được sử dụng cho việc thiết lập kết nối
mới.Cũng giống như các tin nhắn khác, tin nhắn cảnh báo được mã hoá và nén
như được chỉ định trước bởi trạng thái kết nối hiện hành.

Alert Level Types

Alert Description types

2.1.3.3

Handshake Protocol

TLS handshake protocol là một trong những máy trạm được định nghĩa ở mức độ
cao hơn ( defined higher-level clients ) của TLS Record Protocol.
23


Giao thức này được sử dụng để thương lượng các thuộc tính bảo mật của một
phiên.
Thông điệp bắt tay được cung cấp cho TLS Record Layer, nơi mà các thông điệp
này được đóng gói trong một hoặc nhiều cấu trúc TLS Plaintext, chúng được xử
lý và truyền đi theo quy định của trạng thái phiên kết nối hiện tại đang hoạt động.
TLS Handshake protocol bao gồm các bước sau:
-Exchange hello message đồng ý trao đổi các thuật toán, trao đổi ngẫu nhiên các
giá trị và kiểm tra phiên tiếp tục.
-Trao đổi các thông số mật mã cần thiết để cho phép client và server thoả thuận
premaster secret key.
-Các chứng chỉ trao đổi ( exchange certificates ) và thông tin mật mã cho phép
client và server tự chứng thực.
-Tạo ra một master secret key từ premaster secret key và trao đổi các giá trị ngẫu
nhiên.
-Cung cấp các thông số bảo mật cho record layer.
-Cho phép client và server xác minh rằng các máy trong cùng đường mạng tính
toán được các thông số bảo mật và như thế quá trình bắt tay ( handshake ) xảy ra
mà không có kẻ tấn công can thiệp vào.
Cấu trúc của giao thức bắt tay:
enum {

hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
24


} body;
} Handshake;

Chi tiết các gói tin trong Handshake Protocol:

 Hello Message: được sử dụng để trao đổi, tăng cường tính bảo mật giữa

máy trạm và máy chủ .Khi một phiên mới bắt đầu, trạng thái kết nối của
Record Layer sẽ mã hoá, băm và các thuật toán nén được khởi tạo giá trị
Null.Trạng thái kết nối hiện tại được sử dụng cho những thông điệp
thương lượng lại (renegotiation messages).


Hello Request : có thể được gửi đi bởi máy chủ ở bất kì thời
điểm nào.

Ý nghĩa của message này: Hello Request là một thông báo yêu cầu
client nên bắt đầu quá trình “trao đổi thông tin ” một lần nữa bằng
cách gửi cho client một Hello Message khi thuận tiện. Thông báo này
sẽ được client bỏ qua nếu client đang thực hiện một tác vụ khác.Hello
Message cũng có thể được client bỏ qua nếu nó không muốn thực hiện
tác vụ này, hoặc là client sẽ trả lại một thông báo không chấp nhận tin
nhắn. Khi gói tin trao đổi được gửi đi nó sẽ được cấp độ ưu tiên cao
hơn các ứng dụng thông thường, nó sẽ thực hiện việc trao đổi với
client khi không nhận được quá nhiều record từ client. Nếu như server
25