Tải bản đầy đủ (.docx) (37 trang)

tiểu luận môn học an ninh mạng đề tài giao thức ssl và ứng dụng mô phỏng

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.29 MB, 37 trang )

HỌC VIỆN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG

KHOA VIỄN THƠNG I

TIỂU LUẬN MÔN HỌC
AN NINH MẠNG
Đề tài: Giao thức SSL và ứng dụng mô phỏng
Giảng viên

: TS. PHẠM ANH THƯ

Môn học

: An ninh mạng

Mã học phần

: TEL1401M

Nhóm lớp

: 04

Nhóm

: 01

Thành viên

: Trần Ngọc Lâm - B17DCVT204
Nguyễn Doãn Tùng - B17DCVT396



Đỗ Trung Nghĩa - B17DCVT260

Hà Nội, tháng 6/2021

download by :


Bài thi cuối kì mơn ANM

MỤC LỤC
DANH MỤC HÌNH ẢNH.......................................................................................................................... 2
DANH MỤC THUẬT NGỮ VIẾT TẮT................................................................................................... 2
DANH MỤC BẢNG BIỂU........................................................................................................................ 4
PHÂN CÔNG CÔNG VIỆC...................................................................................................................... 4
MỞ ĐẦU..................................................................................................................................................... 4
I. Tổng quan SSL........................................................................................................................................ 5
1.1. SSL là gì ? Tại sao cần sử dụng SSL ?............................................................................................ 5
1.1.1. SSL là gì ?............................................................................................................................ 5
1.1.2. Tại sao cần phải sử dụng SSL ?............................................................................................ 5
1.2. Kiến trúc chồng giao thức SSL....................................................................................................... 6
1.3. Tiến trình SSL.................................................................................................................................. 7
1.3.1. Đàm phán cipher suite.......................................................................................................... 7
1.3.2. Xác thực server..................................................................................................................... 8
1.3.3. Gửi dữ liệu và mã hóa.......................................................................................................... 8
II. Phân tích các giao thức con trong bộ giao thức SSL............................................................................ 8
2.1. Giao thức SSL Record..................................................................................................................... 8
2.2. Giao thức SSL Alert...................................................................................................................... 11
2.3 Giao thức SSL Handshake.............................................................................................................. 11
2.3.1 Giai đoạn 1 – thiết lập khả năng bảo mật........................................................................... 14

2.3.2. Giai đoạn 2 - Xác thực server và trao đổi khóa.................................................................. 15
2.3.3. Giai đoạn 3 - Xác thực client và trao đổi khóa................................................................... 16
2.3.4. Giai đoạn 4 – Kết thúc....................................................................................................... 17
III. Các phương pháp tấn công đối với SSL............................................................................................ 17
3.1. Diffie Hellman MITM Attack....................................................................................................... 17
3.1.1 Giao thức thỏa thuận khóa Diffie Hellman.......................................................................... 17
3.1.2. Tấn cơng Man In The Middle............................................................................................. 18
3.1.3. Giải pháp ngăn ngừa.......................................................................................................... 19
3.2. Tấn công SSLSniff & SSLStrip MITM........................................................................................ 20
3.2.1. Tấn công SSLSniff MITM................................................................................................... 20
3.2.2. SSLStrip MITM Attack........................................................................................................ 21
3.2.3. Giải pháp ngăn ngừa.......................................................................................................... 21
IV. Các ứng dụng phổ biến của SSL hiện nay.......................................................................................... 22

Nhóm 01

1

download by :


Bài thi cuối kì mơn ANM
V. Mơ phỏng việc sử dụng SSL trên web server Apache bằng phần mềm mã nguồn mở OpenSSL.....24
5.1 Thiết lập web server Apache.......................................................................................................... 24
5.2. Thiết lập virtual host với tên miền cho web server Apache......................................................... 25
5.3. Tùy chỉnh file cấu hình DNS local trên máy thật.........................................................................26
5.3. Cài đặt OpenSSL trên web server Apache.................................................................................... 27
KẾT LUẬN............................................................................................................................................... 31
TÀI LIỆU THAM KHẢO........................................................................................................................ 31
KIỂM TRA KẾT QUẢ TRÙNG LẶP TRÊN DOIT............................................................................... 32


DANH MỤC HÌNH ẢNH
Hình 1: Kiến trúc chồng giao thức SSL.......................................................................................................6
Hình 2: Tổng quan quá trình hoạt động của giao thức SSL Record.............................................................9
Hình 3: Tổng quan về định dạng cấu trúc dữ liệu của giao thức SSL Record............................................10
Hình 4: Tổng quan cơ chế giao thức SSL Handshake................................................................................ 13
Hình 5: Thuật tốn trao đổi khóa Diffe-Hellman....................................................................................... 19
Hình 6: Tấn cơng MITM trong Diffe-Hellman........................................................................................... 19
Hình 7: Q trình giao dịch https thơng thường........................................................................................ 20
Hình 8: Tấn cơng SSLSniff MITM.............................................................................................................. 20
Hình 9: Tấn cơng SSL Strip MITM............................................................................................................. 21
Hình 10: Giao diện truy cập của IPMI trên trình duyệt web...................................................................... 23
Hình 11: Giao diện upload chứng chỉ SSL lên trên IPMI........................................................................... 23
Hình 12: Nội dung mặc định của web server Apache khi được cài đặt thành cơng.................................... 25
Hình 13: Tùy chỉnh file hosts..................................................................................................................... 26
Hình 14: Kết quả khi truy cập vào tên miền example.com......................................................................... 27

DANH MỤC THUẬT NGỮ VIẾT TẮT
AES

Advanced Encryption
Standard

Tiêu chuẩn mã hóa tiên tiến

CA

Certificate Authority

Nhà cung cấp chứng thực số


CBC

Cipher block chaining

Mật mã chuỗi khối

DES

Data Encryption Standard

Một chuẩn phương pháp mật mã hóa

DNS

Domain Name System

Hệ thống phân giải tên miền

FTP

File Transfer Protocol

Giao thức truyền tải tập tin

Nhóm 01

2

download by :



Bài thi cuối kì mơn ANM

HMAC

HTTP

HTTPs
ID
IP
IPMI

MAC

MD5
MITM
RN
RSA

SHA-1

SMTP

SSL

TCP
TLS
URL



VPN

Nhóm 01

download by :


Bài thi cuối kì mơn ANM

DANH MỤC BẢNG BIỂU
Bảng 1: Các thuật tốn mã hóa sử dụng trong SSL Record................................................................. 10
Bảng 2: Các kiểu bản tin và thông số của nó trong giao thức SSL Handshake....................................12
Bảng 3: Giao thức thỏa thuận khóa Diffie Hellman............................................................................. 18

PHÂN CƠNG CƠNG VIỆC
Đỗ Trung Nghĩa

Viết lời mở đầu, tìm hiểu mục I, tổng hợp soạn thảo văn bản,
phiên dịch các hình vẽ và các từ khóa sử dụng

Trần Ngọc Lâm

Tìm hiểu mục II, IV, hỗ trợ mơ phỏng và viết kết luận

Nguyễn Dỗn Tùng

Tìm hiểu mục III và V – làm mô phỏng

MỞ ĐẦU

Trên thế giới hiện nay, với việc truyền tải dữ liệu, thực hiện các giao dịch điện tử,
truy nhập web ngày càng được phổ biến và sử dụng rộng rãi, cũng như đóng vai trị hết
sức quan trọng trong cuộc sống của mỗi con người chúng ta. Cho nên, ngày nay các
doanh nghiệp dù lớn hay nhỏ đều rất chú trọng quan tâm đến việc đảm bảo tính an tồn
bảo mật, tính xác thực cho các tác vụ trên, thứ nhất là để nâng cao hình ảnh, thương
hiệu và uy tín cho doanh nghiệp. Đồng thời, đảm bảo được quyền lợi cho người tiêu
dùng, tránh những sự cố mất mát thông tin dữ liệu khơng đáng có. Và để làm được
điều này, hầu như tất cả mọi doanh nghiệp, hay các cá nhân đều tin dùng vào giao thức
SSL – giao thức Secure Sockets Layer.

Nhóm 01

download by :


Bài thi cuối kì mơn ANM
I. Tổng quan SSL
1.1. SSL là gì ? Tại sao cần sử dụng SSL ?
1.1.1. SSL là gì ?
SSL ban đầu được phát triển bởi Netscape và được công bố rộng rãi vào tháng
2/1995 với Version 2.0 nhưng vẫn chứa nhiều lỗ hổng bảo mật cho đến khi Version 3.0
ra mắt vào năm 1996. Phiên bản này được sử dụng cho TLS version 1.0 và được IETF
xác định như một giao thức chuẩn RFC2246 vào tháng 1/1999.Đến nay, SSL được sử
dụng phổ biến trong thương mại điện tử bởi các công ty giải pháp tài chính hàng đầu
trên thế giới.
Có thể hiểu đơn giản là, việc kết nối giữa một trình duyệt web tới bất kỳ điểm nào trên
mạng Internet đều phải đ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
các máy chủ web có thể có bất kỳ sự kiểm sốt nào đối với đường đi của dữ liệu hay
có thể kiểm sốt được liệu có ai đó thâm nhập vào thông tin trên đường truyền. Và

SSL đã được sinh ra với mục đích là một giao thức an ninh thơng tin mạng được sử
dụng nhằm mã hóa và cung cấp kênh an tồn giữa máy chủ web và trình duyệt hay bất
kỳ mạng TCP/IP nào khác. SSL cung cấp cho chúng ta 3 lợi ích chính như sau:
+ Xác thực: Đảm bảo tính xác thực của trang web và máy chủ mà bạn đang trao đổi
dữ liệu và 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ã hóa: Đảm bảo dữ liệu khi trao đổi không 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ã hố để 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 dữ liệu trao đổi không bị sai lệch hay mất mát trong quá
trình truyền dẫn.Với việc sử dụng SSL, các trang web có thể cung cấp khả năng bảo
mật thơng tin, xác thực và tồn vẹn dữ liệu đến người dùng. SSL được tích hợp sẵn
vào các trình duyệt và máy chủ web, cho phép người sử dụng làm việc với các trang
web ở chế độ an toàn.
1.1.2. Tại sao cần phải sử dụng SSL ?
Một trong những ví dụ điển hình cho việc sử dụng SSL đó là trong thương mại
điện tử, chi tiết hơn nữa là trong các q trình trao đổi thơng tin giao dịch. Người dùng
không thể nào chắc chắn xác định được server mà bạn đang trao đổi thông tin. Và SSL
sẽ giúp bạn làm điều đó. Với khả xác thực, SSL cho phép một cách tùy chọn mỗi bên
trao đổi có thể chắc chắn về định danh của phía đối tác.
+ 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ã hố 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ự
Nhóm 01

download by :



Bài thi cuối kì mơn ANM
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ã hố 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.
Hơn nữa, SSL cịn có thể mã hóa kết nối giữa hai bên để truyền thơng tin sau khi xác
thực, đảm bảo thông tin không thể bị truy cập bởi đối tượng thứ ba, tránh lộ thông tin
nhạy cảm như thông tin cá nhân, số tài khoản…khi tiến hành trao đổi.Đ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ư.
Đồng thời, việc sử dụng hàm băm trong mã hóa, SSL sẽ giúp đảm bảo dữ liệu không bị
thay đổi hay mất mát trong q trình truyền dẫn thơng qua cơ chế đặc trưng của hàm
băm là khả năng tự động phát hiện các xáo trộn và thay đổi trong dữ liệu
1.2. Kiến trúc chồng giao thức SSL
Giao thức bảo mật SSL
Giao thức
SSL
Handshake

SMTP
etc…

Lớp ứng
dụng

Giao thức SSL Record


TCP

IP

Network Access
Hình 1: Kiến trúc chồng giao thức SSL

Nhóm 01

download by :

Lớp
truyền tải

Lớp
Internet

Lớp
mạng


Bài thi cuối kì mơn ANM
Trong đó, giao thức SSL bao gồm 2 giao thức con là
+ 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: 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.
SSL Record Protocol cung cấp các dịch vụ bảo mật cơ bản cho nhiều giao thức khác
nhau ở các lớp trên. Trong thực tế, Hyper Text Transfer Protocol (HTTP), cung cấp
dịch vụ trao đổi cho tương tác Web client/server,có thể hoạt động trên đỉnh của SSL.

Ba giao thức lớp trên được định nghĩa như là các phần của SSL: giao thức Handshake,
giao thức Change Cypher Spec và giao thức Alert. Các giao thức mang tính đặc trưng
này được dùng trong phần quản lý trao đổi SSL và được xét đến trong phần sau.
Có hai khái niệm về SSL cần phải biết đó là: SSL connection (kết nối SSL) và SSL
session (phiên SSL):
+ SSL connection: Mỗi kết nối sẽ là một đường truyền tải nhằm cung cấp một dịch vụ
thích hợp. Với SSL, các kết nối đều được coi là ngang hàng và có khả năng trao đổi
nhanh chóng.Và mỗi một kết nối sẽ tương ứng với một phiên.
+ SSL sesssion: Một phiên SSL được tạo ra bằng giao thức Handshake (giao thức bắt
tay) để liên kết giữa client và server. Các phiên trong SSL sẽ định nghĩa 1 tập các tham
số bảo mật bằng mật mã, có thể được chia sẻ giữa nhiều kết nối. Các phiên này được
dùng để tránh việc tốn kém thời gian và tài nguyên hệ thống để đàm phán cho mỗi kết
nối.
1.3. Tiến trình SSL
Quá trình trao đổi thông tin giữa client và server sử dụng SSL được gọi là SSL
handshake, với ba mục tiêu chính:




Đàm phán cipher suite.
Xác thực định danh (tùy chọn).
Hình thành cơ chế bảo mật thông tin, bằng cách thỏa thuận các cơ chế mã hóa.

1.3.1. Đàm phán cipher suite
Cipher suite là một tập các thuật tốn và kích thước khóa được dùng để mã hóa dữ
liệu, bao gồm thơng tin về các thuật tốn trao đổi khóa cơng khai và các thuật tốn
thỏa thuận khóa, và các hàm băm mã hóa. Chính vì vậy, khi một phiên SSL bắt đầu,
client và server sẽ đàm phán xem cipher suite nào mà chúng sẽ sử dụng, và rồi server
sẽ lựa chọn cipher suite nào tốt nhất mà client có.


Nhóm 01

download by :


Bài thi cuối kì mơn ANM
1.3.2. Xác thực server
Trong SSL, việc xác thực là bước tùy chọn nhưng nó lại là bước quan trọng đem
lại sự tin tưởng cho client khi chúng ta cung cấp ứng dụng hay sản phẩm sử dung SSL,
đặc biệt là trong thương mại điện tử.
Để chứng minh server thuộc về tổ chức mà nó khẳng định là nó đại diện, server phải
trình ra chứng chỉ khóa cơng khai của nó cho client. Nếu chứng chỉ này là hợp lệ,
client có thể chắc chắn về định danh của server. Mặt khác, nếu chứng chỉ này không
hợp lệ, client hồn tồn có thể ngừng kết nối và từ chối trao đổi thông tin với server để
tránh những rủi ro phát sinh.
Ví dụ, với RSA, phía client sẽ mã hóa thơng tin khóa bí mật bằng khóa cơng khai của
server, và có được từ chứng chỉ khóa cơng khai, sau đó gửi thơng tin khóa bí mật đã
được mã hóa đến server.Chỉ có server cung cấp khóa cơng khai mà client sử dụng mới
có thể giải mã thơng tin khóa bí mật này bởi vì q trình giải mã phải cần đến khóa
riêng của server.
1.3.3. Gửi dữ liệu và mã hóa.
Sau khi cả client và server đều có thể truy cập đến khóa bí mật chung mà đã được
chia sẻ từ trước. Với mỗi bản tin, chúng sẽ dùng đến hàm băm đã được chọn trong
bước thứ nhất cùng với khóa bí mật, để tính tốn 1 giá trị HMAC nối thêm vào bản tin.
Sau đó, chúng sẽ dùng khóa bí mật và thuật tốn sinh khóa bí mật này, cũng được chọn
ở bước đầu tiên để mã hóa dữ liệu và giá trị HMAC an tồn. Cuối cùng client và server
giờ đây đã có thể trao đổi thơng tin với nhau 1 cách hồn tồn đảm bảo về độ bảo mật
với các dữ liệu đã băm và mã hóa.
II. Phân tích các giao thức con trong bợ giao thức SSL

2.1. Giao thức SSL Record
Như đã đề cập ở phần trên, giao thức SSL được thiết kế dựa trên một phần giao
thức TCP để cung cấp tính bảo mật cho các ứng dụng, dịch vụ đầu cuối dựa trên nền
tảng web. Tuy nhiên, SSL không phải là một giao thức đơn lẻ mà nó hoạt động dựa
theo hai lớp giao thức như được minh họa ở Hình 1. Ta có thể dễ dàng thấy được có
một lớp giao thức sử dụng TCP trực tiếp, chính là giao thức SSL Record. Lớp giao
thức này có khả năng cung cấp các dịch vụ bảo mật cơ bản cho các giao thức lớp cao
hơn.
Để nói sâu hơn về giao thức này, ta cần phải biết được tác dụng của nó. Thứ nhất, giao
thức SSL Record có khả năng cung cấp tính bảo mật cho các phiên kết nối SSL, trong
đó giao thức này sẽ định nghĩa một khóa bí mật được chia sẽ, và sử dụng khóa này để
mã hóa quy ước cho các dữ liệu SSL. Thứ hai, giao thức này đem lại tính tồn vẹn cho
dữ liệu truyền, bởi vì dữ liệu trước khi truyền sẽ được gán thêm một giá trị của mã xác
thực thơng điệp – MAC.
Nhóm 01

download by :


Bài thi cuối kì mơn ANM
Hình vẽ dưới đây sẽ thể hiện rõ tồn bộ q trình hoạt động của giao thức SSL Record.
Dữ liệu ứng dụng

Phân mảnh

Nén

Thêm MAC

Mã hóa


Gắn SSL Record header

Hình 2: Tổng quan quá trình hoạt động của giao thức SSL Record
Đầu tiên, khi giao thức SSL Record nhận được một bản tin sắp phải được truyền đi, nó
sẽ phân mảnh dữ liệu đó ra làm nhiều khối nhỏ, các khối dữ liệu này sẽ có kích thước
khoảng 2

14

bytes hoặc ít hơn.

Sau đó, các khối dữ liệu này sẽ được nén tùy chọn, quá trình nén dữ liệu phải đảm bảo
hai yêu cầu là không để mất dữ liệu và không làm tăng độ dài của dữ liệu q 1024
bytes.
Tiếp theo, nó sẽ tính tốn một giá trị xác thực thơng điệp dữa trên khóa bí mật dùng
chung, rồi gán vào khối dữ liệu đã được nén.
Dữ liệu cùng với giá trị xác thực thông điệp sẽ được tiếp tục mã hóa bằng khóa đối
xứng. Q trình mã hóa sẽ khơng được phép làm tăng độ dài của dữ liệu quá 1024
14
bytes, do đó tổng độ dài của dữ liệu sẽ được giới hạn ở 2 + 2048 bytes. Các thuật
tốn mã hóa sau được cho phép sử dụng trong giao thức SSL Record.

Nhóm 01

download by :


Bài thi cuối kì mơn ANM
Mã hóa khối

Thuật tốn
AES
IDEA
RC2-40
DES-40
DES
3DES
Bảng 1: Các thuật tốn mã hóa sử dụng trong SSL Record
Với mã hóa luồng, các dữ liệu đã nén sẽ được cộng thêm giá trị MAC trước khi q
trình mã hóa xảy ra và giá trị MAC cũng sẽ được mã hóa theo. Cịn với mã hóa khối,
giá trị MAC sẽ có thể được đệm thêm các byte trước khi được mã hóa. Phần đệm thêm
sẽ có dạng gồm nhiều byte đệm được theo sau bởi một byte chỉ rõ chiều dài của phần
đệm. Tổng số lượng byte đệm sẽ được tính tốn sao cho nhỏ nhất để kích thước của
tổng dữ liệu được mã hóa (dữ liệu đã nén + giá trị MAC + phần đệm thêm) là bội số
của chiều dài khối mã hóa.
Và bước cuối cùng, dữ liệu sau khi được mã hóa sẽ được thêm tiêu đề bao gồm các
trường của giao thức SSL Record như sau:
+ Content Type (8 bit): thể hiện giao thức lớp trên được dùng để xử lý các phân mảnh
dữ liệu đi kèm.
+ Major Version (8 bit): chỉ ra phiên bản giao thức SSL tối đa có thể sử dụng.
+ Minor Version (8 bit): chỉ ra phiên bản giao thức SSL tối thiểu có thể sử dụng.
+ Compressed Length (16 bit): Thể hiện độ dài theo byte của phân mảnh dữ liệu đã
nén, giá trị lớn nhất sẽ là 2

14

Mã hóa

Loại dữ
liệu


+ 2048.
Phiên bản
chính

Phiên
bản phụ

Độ dài nén

Bản rõ
(nén tùy chọn)

MAC (0,16 hoặc 20 bytes)

Hình 3: Tổng quan về định dạng cấu trúc dữ liệu của giao thức SSL Record
Nhóm 01

download by :


Bài thi cuối kì mơn ANM

2.2. Giao thức SSL Alert
Giao thức SSL Alert được sử dụng để truyền thông tin cảnh báo cũng như là trạng
thái hiện tại về phiên kết nối SSL với đầu cuối bên nhận dữ liệu.
Bản tin trong giao thức này sẽ bao gồm 2 bytes. Byte đầu tiên sẽ thể hiện giá trị cảnh
báo, tương đương với giá trị “1” hoặc là nguy hiểm tương ứng với giá trị “2”. Nếu mức
độ phát hiện được là nguy hiểm, SSL sẽ lập tức chấm dứt kết nối. Các kết nối tại các
phiên khác sẽ vẫn có thể được tiếp tục nhưng sẽ khơng có kết nối nào trên phiên được

đánh giá là nguy hiểm được khởi tạo thêm. Còn byte thứ hai sẽ chứa một giá trị để thể
hiện các cảnh báo đặc trưng, ví dụ như đối với các cảnh báo ở mức độ nguy hiểm:
+ unexpected_message: dữ liệu truyền khơng thích hợp.
+ bad_record_mac: giá trị MAC khơng chính xác.
+ decompression_failure: q trình giải nén gặp vấn đề, ví dụ như khơng thể giải nén
hoặc q trình giải nén cho ra dữ liệu có độ dài vượt quá mức tối đa cho phép.
+ handshake_failure: quá trình bắt tay gặp vấn đề, ví dụ như hai bên nhận và gửi
không thể đưa ra các thông số bảo mật thích hợp để kết nối với nhau.
+ illegal_parameter: trường giá trị khơng thích hợp.
Cịn đối với các giá trị ở mức cảnh báo:
+ close_notify: thông báo cho bên nhận rằng bên gửi sẽ không gửi thêm dữ liệu nào
nữa trong phiên kết nối này. Mỗi bên sẽ được gửi một yêu cầu close_notify cảnh báo
trước khi kết thúc quá trình nhận và ghi dữ liệu trong một phiên kết nối.
+ no_certificate: phiên kết nối được tạo không sử dụng chứng chỉ xác thực thích hợp.
+ bad_certificate: phiên kết nối sử dụng chứng chỉ xác thực khơng thích hợp.
+ unsupported_certificate: chứng chỉ xác thực không được hỗ trợ trong phiên kết nối
+ certificate_expired: chứng chỉ xác thực sử dụng trong phiên truyền đã hết hạn thời
gian sử dụng.
2.3 Giao thức SSL Handshake
Đây chính là lớp giao thức con quan trọng nhất trong SSL. Giao thức này cho
phép phía server và client chứng thực với nhau và cùng bắt tay thương lượng về các
tham số như cơ chế mã hóa, thuật tốn MAC và khóa bí mật được sử dụng để bảo vệ
dữ liệu được truyền trong giao thức SSL Record. Giao thức SSL Handshake thường
được sử dụng trước khi dữ liệu của ứng dụng được gửi đi.
Nhóm 01

download by :


Bài thi cuối kì mơn ANM

Giao thức này sẽ bao gồm một chuỗi các bản tin được trao đổi giữa client và server, và
mỗi bản tin về tổng quát sẽ đều có ba trường như sau:
+ Type (1 byte): giá trị thể hiện dạng của bản tin.
+ Length (3 bytes): biểu thị độ dài của bản tin theo bytes.
+ Content (>=0 bytes): miêu tả các tham số đi kèm với bản tin.
Kiểu bản tin
Hello_request
Client_hello
Server_hello
Certificate
Server_key_exchange
Certificate_request
Server_done
Certificate_verify
Client_key_exchange
Finished
Bảng 2: Các kiểu bản tin và thơng số của nó trong giao thức SSL Handshake
Tiếp theo, hình vẽ dưới đây sẽ có thể cho ta thấy được cái nhìn tổng quan về quá trình
thiết lập kết nối giữa client và server từ lúc ban đầu cho đến khi kết thúc. Q trình này
sẽ có thể được chia thành bốn giai đoạn nhỏ, như sau:

Nhóm 01

download by :


Bài thi cuối kì mơn ANM

Khóa cơng khai Client


Chứng chỉ của server

(2)

Yêu cầu chứng chỉ của client
Kiểm tra chứng chi của server
RNs

RNc

RNc

RNs

(3)
PMSRNs

RNc

RNs

PMS

MS
MS

(4)

Hình 4: Tổng quan cơ chế giao thức SSL Handshake



Nhóm 01

download by :


Bài thi cuối kì mơn ANM

2.3.1 Giai đoạn 1 – thiết lập khả năng bảo mật
Đây là giai đoạn được thực hiện để bắt đầu khởi tạo một kết nối logic và thiết lập
khả năng bảo mật bắt đầu từ phía client đến server, thơng qua việc gửi bản tin
client_hello với những thông số sau đây:
+ Version: phiên bản chứng chỉ SSL mới nhất mà client biết.
+ Random: bao gồm một nhãn thời gian 32 bit và một chuỗi 28 bytes sinh bởi một bộ
khởi tạo số ngẫu nhiên. Hai giá trị này sẽ được sử dụng cho phiên truyền và trong suốt
q trình trao đổi khóa để tránh tấn công lặp lại.
+ Session ID: thể hiện giá trị ID của phiên truyền, tuy nhiên giá trị này có thể thay đổi
được. Nếu như Session ID khác 0 nghĩa là phía client sẽ muốn cập nhật tham số của
của phiên kết nối đã và đang tồn tại hoặc là tạo một phiên truyền mới. Cịn Session ID
bằng 0, thì tức là bên client đang muốn thiết lập một kết nối mới trên một phiên truyền
mới.
+ CipherSuite: đây là 1 danh sách mà chứa những bộ biên dịch của các thuật tốn mã
hóa được hỗ trợ bởi phía client, và sẽ có độ ưu tiên theo thứ tự giảm dần. Mỗi thành
phần trong danh sách (mỗi bộ mã hóa) sẽ định nghĩa cả khóa để trao đổi và một
CipherSpec (bao gồm CipherAlgorithm, MacAlgorithm, CipherType, HashSize, Key
Material và IV Size).
+ Compression Method: đưa ra danh sách các những phương thức nén mà client hỗ
trợ.
Sau khi phía client gửi đi bản tin client_hello, nó sẽ chờ nhận lại được bản tin
server_hello mà đáp ứng được những thông số đưa ra trong bản tin client_hello. Trong

bản tin server_hello, nó sẽ đưa ra những thơng số có thể chấp nhận cho bên client. Đầu
tiên là trường Version, trường này sẽ phải đưa ra giá trị phiên bản chứng chỉ SSL có
thể sử dụng được đối với cả hai bên. Tiếp theo là trường Random, phía server sẽ sinh
ra một nhãn thời gian và một bộ số ngẫu nhiên hoàn toàn độc lập với client, tất nhiên
là để nhằm mục đích ngăn tấn cơng lặp lại. Sau đó là đến trường Session ID, nếu
trường SessionID của client khác 0, thì giá trị tương tự cũng được dùng bởi bên server,
ngược lại thì trường SessionID của server sẽ chứa giá trị của một phiên truyền mới.
Cuối cùng là hai trường CipherSuite và Compression, thì server sẽ chọn một giá trị
phù hợp từ danh sách đề xuất của client đưa ra.
Để có thêm cái nhìn chi tiết về trường CipherSuite, ta phải thấy được các thông số chi
tiết của trường này. Về thành phần đầu tiên xuất hiện trong trường CipherSuite sẽ là
phương thức trao đổi khóa bí mật, ví dụ như:

Nhóm 01

download by :


Bài thi cuối kì mơn ANM
+ RSA: khóa bí mật được mã hóa với khóa cơng khai RSA của bên nhận. Tất nhiên là
public-key certificate cho khóa bên nhận sẽ phải được tạo sẵn.
+ Fixed Diffie-Hellman: đây là sự trao đổi khóa Diffie-Hellman trong certificate của
server chứa các thơng số công khai Diffie-Hellman được ký bởi Certificate Authority
(CA). Nghĩa là certificate khóa cơng khai sẽ phải chứa các thơng số khóa cơng khai
của Diffie-Hellman. Đồng thời phía client cũng sẽ chứa sẵn các thơng số khóa cơng
khai của Diffie-Hellman đó trong certificate nếu chứng thực client được yêu cầu hoặc
trong một bản tin trao đổi khóa. Phương thức này mang lại kết quả một khóa bí mật cố
định giữa hai đầu, dựa trên tính tốn Diffie-Hellman sử dụng khóa cơng khai cố định.
+ Ephemeral Diffie-Hellman: phương pháp được sử dụng để tạo khóa tạm thời và chỉ
sử dụng được một lần. Trong trường hợp này, khóa cơng khai Diffie-Hellman được

trao đổi, và được ký sử dụng khóa bí mật RSA hoặc DSS của bên gửi. Bên nhận có thể
sử dụng khóa cơng khai tương ứng để xác minh chữ ký. Sau đó Certificate được sử
dụng để xác thực khóa cơng khai. Điều này đem lại sự bảo đảm nhất định của ba lựa
chọn Diffie-Hellman bởi vì nó là kết quả của sự tạm thời và khóa xác thực.
+ Anonymous Diffie-Hellman: thuật tốn Diffie-Hellman cơ bản được sử dụng, tuy
nhiên khơng được chứng thực. Nghĩa là mỗi lần một bên gửi thơng số Diffie-Hellman
cơng khai của nó cho bên kia thì sẽ không được xác thực. Và tất nhiên, điều này gần
như sẽ tạo ra cơ hội có thể bị tấn cơng bởi các cuộc tấn cơng Man-in-the-middle, trong
đó kẻ tấn cơng sẽ có khả năng điều khiển cả nhóm anonymous Diffie-Hellman.
Tiếp theo sau đó là các thơng số khác xuất hiện trong CipherSpec bao gồm:
+ Cipher Algorithm: một vài thuật toán kể đến : RC4, RC2, DES, 3DES, DES40,
IDEA.
+ MAC Algorithm: MD5 hoặc SHA-1.
+ Cipher Type: luồng hoặc khối.
+ Hash Size: 0, 16 (cho MD5), hay 20 (cho SHA-1) bytes.
+ Key Material: thứ tự của các bytes mà chứa dữ liệu được dùng trong sinh khóa.
+ IV Size: kích thước của giá trị khởi tạo cho mã hóa Cipher Block Chaining (CBC).
2.3.2. Giai đoạn 2 - Xác thực server và trao đổi khóa
Sau khi kết thúc giai đoạn 1, phía server sẽ bắt đầu giai đoạn 2 bằng cách gửi
chứng thực của nó nếu nó cần được xác thực, bản tin này sẽ chưa một hoặc một chuỗi
các certificate X.509. Không chỉ thế, bản tin chứng thực cũng sẽ được yêu cầu gửi khi
có bất kỳ một phương pháp trao đổi khóa nào được chấp thuận và sử dụng, ngoại trừ
anonymous Diffie-Hellman.

Nhóm 01

download by :


Bài thi cuối kì mơn ANM

Sau đó, một bản tin server_key_exchange sẽ được gửi đi nếu nó được yêu cầu. Nếu
như bản tin này không được yêu cầu gửi từ phía client thì chứng tỏ server đã gửi
chứng thực với các tham số của fixed Diffie-Hellman (bởi vì nếu fixed Diffie-Hellman
được dùng,thì thơng điệp chứng thực có chức năng như là thơng điệp trao đổi khóa của
server vì nó chứa các tham số Diffie-Hellman công khai của server) hoặc là q trình
trao đổi khóa RSA đã được thực hiện.
Các trường hợp mà bên phía client yêu cầu gửi bản tin server_key_exchange:
- Anonymous Diffie-Hellman: Nội dung thông điệp bao gồm hai giá trị Diffie-Hellman
tồn cụccùng với khóa Diffie-Hellman của server.
- Ephemeral Diffie-Hellman: nội dung thông điệp bao gồm 3 tham số Diffie-Hellman
cung cấp cho anonymous Diffie-Hellman, cùng với một chữ kí của các tham số này.
- Trao đổi khóa RSA: trong đó server sẽ sử dụng RSA nhưng có một khóa chữ kí chỉ
của RSA. Theo đó, client sẽ khơng thể gửi đi cách đơn giản một khóa bí mật được mã
hóa với khóa cơng khai/bí mật RSA phụ và sử dụng thơng điệp server_key_exchanged
để gửi khóa cơng khai.Nội dung thơng điệp bao gồm hai tham số của khóa cơng khai
RSA phụ(số mũ và số dư) cùng với một chữ ký của các tham số này.
Kế đến, server có thể yêu cầu một thơng điệp chứng thực từ phía client, hay cịn gọi là
certificate_request, mà trong đó thơng điệp này bao gồm hai thông số là
certificate_type và certificate_authorities. Giá trị certificate_type sẽ chỉ ra giải thuật
khóa cơng khai được sử dụng như RSA hay DSS. Thông số thứ 2 của thông điệp
certificate_request là một danh sách các tên của những CA đặc biệt được chấp nhận
Cuối cùng trong giai đoạn này, phía server sẽ ln được u cầu gửi một bản tin là
server_done để thơng báo rằng q trình xác thực server đã được hoàn thành. Sau khi
gửi đi bản tin này, phía server sẽ chờ hồi đáp của bên client.
2.3.3. Giai đoạn 3 - Xác thực client và trao đổi khóa
Trong khi nhận thơng điệp server_done, bên client sẽ xác nhận xem phía server đã
cung cấp một chứng chỉ hợp lệ hay chưa nếu được yêu cầu và kiểm tra xem các thơng
số của bản tin server_hello có được chấp nhận hay không. Nếu tất cả điều kiện đều
thoả mãn, bên client sẽ gửi một hoặc nhiều bản tin trở lại cho server. Cịn nếu phía
server u cầu một chứng thưc, thì client sẽ bắt đầu giai đoạn này bằng cách gửi một

thơng điệp chứng thực. Nếu như khơng có chứng thực phù hợp nào hợp lệ, phía client
sẽ gửi một cảnh báo là no_certificate thay thế.
Kế đến là bản tin client_key_exchange sẽ phải được gửi đi trong giai đoạn này. Nội
dung của bản tin sẽ được phụ thuộc vào kiểu trao đổi khóa giữa client và server. Thể
hiện như sau:

Nhóm 01

download by :


Bài thi cuối kì mơn ANM
+RSA: client sinh một trường 48 byte pre-master secret và mã hóa với khóa cơng khai
từ chứng thực của server hoặc khóa RSA phụ từ thơng điệp server_key_exchange. Nó
dùng để tính tốn một master secret (đây là một giá trị được sử dụng một lần với độ
dài là 48 byte và được sinh ra cho phiên này bằng cách trao đổi khóa an tồn)
+ Ephemeral hoặc Anonymous Diffie-Hellman: các tham số Diffie-hellman công
khai của client được gửi đi.
+Fixed Diffie-Hellman: các tham số Diffie-Hellman công khai của client được gửi đi
trong một thơng điệp certificate,vì vậy nội dung của thông điệp là null.
Cuối cùng, trong giai đoạn này, client sẽ gửi 1 message certificate_verify để cung cấp
tính xác thực cho chứng thực mà client đã gửi đi. Thơng điệp này chỉ được gửi theo
sau bất kì một client certificate nào mà đã được đánh dấu là có khả năng sử dụng
(nghĩa là tất cả certificate ngoại trừ những cái chứa tham số của fixed Diffie-Hellman).
2.3.4. Giai đoạn 4 – Kết thúc
Giai đoạn này đánh dấu việc hồn thành q trình thiết lập của một phiên kết nối
an toàn, client sẽ gửi đi một bản tin change_cipher_spec và ghi đè giá trị CipherSpec
đệm lên giá trị CipherSpec hiện tại. Tuy nhiên bản tin này không được xem là một
phần của giao thức bắt tay nhưng được gửi đi bằng cách sử dụng giao thức Change
Cipher Spec. Sau đó bên client sẽ ngay lập tức gửi đi thơng điệp kết thúc, thông điệp

này sẽ xác minh rằng quá trình trao đổi khóa bí mật và xác thực giữa hai bên client và
server có thành khơng hay khơng. Cuối cùng khi server hồi đáp lại thơng điệp này, nó
sẽ gửi đi bản tin change_cipher_spec của chính nó và chuyển trạng thái của
CipherSpec hiện tại sang treo rồi mới gửi đi thơng điệp kết thúc của nó đi. Ở thời điểm
này, có thể thấy được rằng q trình bắt tay giữa client và server đã hồn tất và chúng
có thể bắt đầu trao đổi các dữ liệu ứng dụng một cách an tồn.
III. Các phương pháp tấn cơng đối với SSL
3.1. Diffie Hellman MITM Attack
3.1.1 Giao thức thỏa thuận khóa Diffie Hellman
Vào năm 1976, giao thức thỏa thuận khóa Difie-Hellman được công bố lần đầu
tiên bởi hai nhà mật mã học của Mỹ đó là Whitfield Diffie và Martin Hellman dựa trên
bài tốn về logarrit rời rạc, và nó đã trở thành một phương thức trao đổi khóa phổ biến
đến tận ngày nay. Như chúng ta đã biết môi trường truyền các gói tin mang dữ liệu,
thơng tin là khơng được an tồn và các gói tin có thể bị mất và giả mạo bất cứ lúc nào.
Mục đích của giao thức này để giải quyết vấn đề trên. Nó thiết lập một khóa bí mật
dùng chung để bên gửi có thể mã hóa dữ liệu cịn bên nhận có thể dùng nó để giải mã
những gói tin nhận được. Điểm đặc biệt là nó khơng cần có sự thỏa thuận trước về

Nhóm 01

download by :


Bài thi cuối kì mơn ANM
khóa bí mật giữa hai bên và mức độ an toàn của giao thức này dựa trên độ khó của bài
tốn logarit rời rạc.
Bài tốn logarit rời rạc được hai nhà mật mã học áp dụng vào như sau: Giả sử có hai
người A và B muốn thực hiện trao đổi khóa. Đầu tiên A và B sẽ thống nhất sử dụng
chung một bộ tham số miền (p, g). Trong đó p, g là hai số nguyên tố với p lớn và g là
căn nguyên thủy modulo p. Bộ tham số (p, g) này không cần giữ bí mật (được cơng

khai). Sau đó A chọn một số a và giữ bí mật số a này. B cũng chọn một số b và giữ bí
mật số b.
a

Tiếp đó tại A sẽ tính tốn Xa = g mod p (1) và gửi Xa cho B, còn B tính và gửi Yb =
b
g mod p (2) cho A.
Trên cơ sở đó A tính:
a

b a

ab

Yb mod p = (g ) mod p = g mod p =Ks (3)
Còn B tính:
b

a b

ab

Xa mod p = (g ) mod p = g mod p =Ks (4)
Ta có thể thấy A và B đã tính chung ra một giá trị đó là Ks. Giá trị này có thể dùng để
dẫn xuất ra các khóa phiên bí mật để sử dụng cho các thuật tốn mã hóa khóa đối
xứng. Cụ thể giao thức thỏa thuận khóa Diffie Hellman nguyên thủy được thể hiện như
trên bảng dưới
A
Bí mật
a

a
a
a, Ks
Bảng 3: Giao thức thỏa thuận khóa Diffie
Hellman 3.1.2. Tấn cơng Man In The Middle
Như chúng ta có thể thấy nếu SSL sử dụng thuật tốn trao đổi khóa Diffie
Hellman đã trình bày ở trên thì ở phase 2 và 3 ở bước Share Key Exchange và Client
a

b

Key Exchange sẽ thực hiện việc trao đổi tham số Xa = g mod p (1) và Yb = g mod p
(2)
tương tự như ở hình dưới:

Nhóm 01


download by :


Bài thi cuối kì mơn ANM

Hình 5: Thuật tốn trao đổi khóa Diffe-Hellman

Ta có thể thấy khơng có sự xác thực nào diễn ra đảm bảo đúng A là người gửi tham số
Xa= ga mod p đến B. Kẻ tấn cơng có thể lợi dụng điều này, sử dụng phương pháp Man
In The Middle để tấn công. MITM là một loại tấn công xen giữa, khi mà kẻ tấn công bí
mật xen vào giữa q trình trao đổi thơng tin của hai bên, nhằm nghe trộm hoặc mạo
danh một trong các bên. Cụ thể trong trường hợp này như sau:


Hình 6: Tấn công MITM trong Diffe-Hellman
Đầu tiên kẻ tấn công sẽ xen vào giữa q trình trao đổi thơng tin của A và B. Tại đây
a
kẻ tấn công sẽ lấy gói tin của A lấy được tham số Xa= g mod p (1). Tiếp đó từ tham số
Xa ấy kẻ tấn cơng sẽ giải mã và tìm ra được hai tham số g và p. Sau khi có được tham
số g và p, kẻ tấn công sẽ giả dạng A bằng cách tạo một số bí mật t (giống như A có số
t
bí mật là a vậy) và gửi tham số giả mạo g mod b đến B và cả về A. B nghĩ đó là
b

A gửi và sẽ gửi tham số Yb= g mod p (2) lại cho kẻ tấn cơng và thiết lập tính tốn gửi
mã. Điều đó cũng xảy ra tương tự với A khi A nghĩ kẻ tấn cơng là B nên sẽ thiết lập
tính tốn gửi mã Ks. Và như vậy kẻ tấn cơng có thể lấy được những dữ liệu từ A và B
gửi đến, sửa đổi, chuyển tiếp để thực hiện việc giả danh, lừa đảo.
3.1.3. Giải pháp ngăn ngừa
Mức độ an toàn của thuật tốn thỏa thuận khóa Diffe-Hellman phụ thuộc vào độ
a
khó của bài tốn logarit rời rạc khi mà với giá trị X = g mod p ta cần phải tính ngược
về tìm được hai giá trị g và p. Vì thế để tăng độ khó bài tốn cũng như độ an tồn của
thuật tốn ta cần phải chọn p và g là những số ngun tố lớn.
Ngồi ra có thể phát triển thêm một bộ định thời gian cho gói tin. Tức là khi gói tin
truyền đi trong mơi trường mạng với một thời gian nhất định thì gói tin sẽ bị hủy. Điều
Nhóm 01

download by :


Bài thi cuối kì mơn ANM
đó sẽ khiến cho thời gian kẻ tấn cơng có thể giải tìm ra giá trị g và p sẽ bị giảm xuống,

gây khó khăn, tạo áp lực về mặt thời gian cho những kẻ xấu muốn chiếm đoạt thông
tin.
3.2. Tấn công SSLSniff & SSLStrip MITM
Đây là 2 cách tấn công mà các kẻ tấn công lợi dụng tâm lý lơ là của người dùng
khi người sử dụng thường bỏ qua những thông báo nhỏ hoặc không quá để ý sự thay
đổi của đường dẫn URL đến website. Từ đó kẻ tấn cơng có thể giả dạng server, trao
đổi thông tin trực tiếp với người dùng.
3.2.1. Tấn cơng SSLSniff MITM
Hình dưới thể hiện một q trình https thơng thường giữa các client với các server

Hình 7: Q trình giao dịch https thơng thường
Khi đó kẻ tấn công sẽ dùng phương thức MITM xen vào giữa q trình trao đổi thơng
thường giữa client với server. Đối với client kẻ tấn cơng sẽ đóng giả trở thành các
server trao đổi cịn về phía server thật kẻ tấn cơng sẽ giao dịch như một client bình
thường.

Hình 8: Tấn cơng SSLSniff MITM
Nhóm 01

download by :


Bài thi cuối kì mơn ANM
Để có thể giả dạng Server các kẻ tấn công sẽ tạo ra một chứng thư số (digital
certificate) giả mạo Server. Chứng thư số là một loại chứng thư điện tử do tổ chức dịch
vụ chứng thực chữ ký số cung cấp cho doanh nghiệp. Có thể nói chứng thư số như một
“chứng minh thư” của doanh nghiệp nhằm nhiệm vụ xác nhận danh tín của doanh
nghiệp đó trong mơi trường Internet. Chứng thư số bao gồm các thơng tin của doanh
nghiệp đó và một public key, được tổ chức có thẩm quyền xác định, thẩm tra cung cấp.
Và chứng thư số của kẻ tấn công tạo ra sẽ khá giống với chứng thư số của Server chỉ

khác một số trường và đặc biệt khóa cơng khai của Server đó đã được thay thế bằng
khóa cơng khai của kẻ tấn cơng. Khi đó kẻ tấn cơng có thể giả mạo Server đó với các
người dùng. Tất nhiên trong quá trình trao đổi, trên Client sẽ hiển thị thông báo cảnh
báo warning tuy nhiên với những người không để ý quá về vấn đề này thường sẽ bỏ
qua. Kết quả những thông tin giao dịch của Client đều bị kẻ tấn công nắm bắt được.
3.2.2. SSLStrip MITM Attack
Thực tế cho thấy rằng hầu hết người truy nhập web không gõ chuỗi ký tự “http://”
hoặc “https://” để truy nhập web.Nói cách khác chúng ta thường sử dụng SSL một
cách gián tiếp thông qua các HyperLinks (siêu liên kết) và Redirection Messages được
xử lý bởi các trình duyệt web.
Kẻ tấn cơng có thể lợi dụng điều này để xử dụng phương pháp MITM, xen vào giữa
kết nối Client với Server, thay thế các HyperLinks “https://.....” (có áp dụng SSL)
thành “http://...” ( không sử dụng SSL ) cũng như những Redirection Messages ( tin
nhắn chuyển hướng ) tới các trang “https://...” thành các trang “http://...” . Nếu làm
được như thế thì kẻ tấn cơng đã gỡ bỏ được SSL từ Client, chỉ cịn là kết nối http thơng
thường với Client và https đến Server như hình dưới

Hình 9: Tấn cơng SSLStrip MITM
Vì chỉ cịn là kết nối http thơng thường khơng được SSL bảo vệ, kẻ tấn cơng hồn tồn
có thể lấy được thơng tin người dùng nhằm những mục đích xấu.
3.2.3. Giải pháp ngăn ngừa

hai phương thức tấn cơng trên hầu như đều sẽ có thơng báo và hiển thị sự thay
đổi trên máy người dùng (nếu với tấn cơng SSLSniff MITM sẽ có thơng báo cịn trên
tấn cơng SSL Strip MITM thì đường dẫn URL sẽ có sự thay đổi). Từ đó có thể thấy
Nhóm 01

download by :



×