BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT TP. HCM
KHOA ĐIỆN - ĐIỆN TỬ
BỘ MÔN ĐIỆN TỬ - VIỄN THÔNG

ĐỒ ÁN MÔN HỌC 3

NGÀNH:CÔNG NGHỆ KỸ THUẬT MÁY TÍNH
Đề tài:
TÌM HỂU GIAO THỨC SSL VÀ ỨNG
DỤNG BẢO MẬT TRONG HỆ THỐNG
MẠNG NỘI BỘ
TP. HỒ CHÍ MINH-1/2012
GVHD: Lê Minh
SVTH : Lê Ngọc Tuấn – Nguyễn Phúc Viên
MSSV : 08119070 08119073

Đại Học Sư Phạm Kỹ Thuật
Khoa Điện – Điện Tử
Bộ Môn Điện Tử Viễn Thông
CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆTNAM
Độc Lập – Tự Do – Hạnh Phúc
Ngày……tháng … năm 201
PHIẾU CHẤM ĐỒ ÁN MÔN HỌC…
(Dành cho người hướng dẫn)
1. Họ tên sinh viên : ……………………………………………………………………………
MSSV:
…………………………….……………………………………… … MSSV:……
2. Tên đề tài :
………………………………………………………………………………………………
………………………………………………………………………………………………

Phần A
GIỚI THIỆU
LỜI NÓI ĐẦU
Trang 1
Đồ án môn học 3 Trang 2
Lời đầu tiên nhóm thực hiện đề tài xin cảm ơn thầy cô giáo chuyên ngành điện
tử, cảm ơn thầy Lê Minh đã hướng dẫn tận tình nhóm thực hiện đề tài trong quá trình
thực hiện đồ án này.
Trong các giao dịch điện tử trên mạng và trong các giao dịch thanh toán trực
tuyến, thông tin/dữ liệu trên môi trường mạng Internet không an toàn thường được bảo
đảm bởi cơ chế bảo mật thực hiện trên tầng vận tải có tên Lớp cổng bảo mật SSL
(Secure Socket Layer) - một giải pháp kỹ thuật hiện nay được sử dụng khá phổ biến
trong các hệ điều hành mạng máy tính trên Internet. SSL là giao thức đa mục đích được
thiết kế để tạo ra các giao tiếp giữa hai chương trình ứng dụng trên một cổng định trước
(socket 443) nhằm mã hoá toàn bộ thông tin đi/đến, được sử dụng trong giao dịch điện
tử như truyền số liệu thẻ tín dụng, mật khẩu, số bí mật cá nhân (PIN) trên Internet. Giao
thức SSL được hình thành và phát triển đầu tiên nǎm 1994 bởi nhóm nghiên cứu
Netscape dẫn dắt bởi Elgammal, và ngày nay đã trở thành chuẩn bảo mật thực hành trên
mạng Internet. Phiên bản SSL hiện nay là 3.0 và vẫn đang tiếp tục được bổ sung và hoàn
thiện.
Do kiến thức còn hạn hẹp và trình độ về chuyên môn còn hạn chế nên sẽ khó
tránh khỏi những thiếu sót,khuyết điểm.Rất mong được sự đóng góp ý kiến và chỉ bảo
nhiệt tình từ phía các thầy cô để đề tài được hoàn thiện hơn.
Tp.HCM, Tháng 1 năm 2012
MỤC LỤC
Phần A GIỚI THIỆU Trang
Trang 2
Đồ án môn học 3 Trang 3
Lời nói đầu 2
Mục lục 3

- Để làm được điều này người ta đã ứng dụng giao thức SSL để bảo vệ các dữ liệu
trong quá trình trao đổi giữa tất cả các dịch vụ mạng sử dụng TCP/IP để hỗ trợ
các tác vụ truyền thông mạng giữa máy chủ và máy khách.
- Giao thức SSL đầu tiên do Netscape phát triển, mục đích để bảo mật dữ liệu
gửi/nhận trên Internet của các giao thức thuộc lớp ứng dụng như HTTP, LDAP
hay POP3. SSL sử dụng giao thức TCP để cung cấp các kết nối bền vững, bảo
mật và được xác thực giữa các điểm cuối với nhau (ví dụ như giữa client và
server). Mặc dù có thể sử dụng SSL để bảo vệ dữ liệu liên quan đến bất kỳ dịch
vụ nào, nhưng SSL chủ yếu được dùng trong các ứng dụng HTTP (server và
client). Ngày nay hầu hết các HTTP server đều hỗ trợ các phiên SSL, ở phía
client các trình duyệt Internet Explorer và Netscape Navigator đều hỗ trợ SSL.
Hình 1.1: SSL giữa tầng ứng dụng và tầng TCP/IP
1.1.2.Nhiệm vụ và cấu trúc của SSL
Trang 5
Đồ án môn học 3 Trang 6
- Cấu trúc của SSL và giao thức SSL tương ứng được minh họa trong hình 2 (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 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 2 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.

về vai trò của từng giao thức chúng ta hãy xem xét hai khái niệm mang tính nền
tảng liên quan tới việc sử dụng SSL.
- Để 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 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
Trang 7
Đồ án môn học 3 Trang 8
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

một bộ các tham số ví dụ thuật toán sẽ sử dụng, số hiệu phiên v.v Khi một
phiên SSL giữa một client và một server được thiết lập bằng giao thức SSL
Handshake Protocol thì tất cả các kết nối sau này được thiết lập giữa cặp
server/client đó sẽ sử dụng chung bộ tham số đó mà không phải tiến hành thoả
thuận lại. Điều đó có nghĩa là trong một phiên SSL giữa một client và một server
có thể có nhiều kết nối giữa client và server đó. Về lý thuyết cũng có thể có nhiều
phiên SSL dùng chung một kết nối, nhưng trên thực tế không sử dụng đến khả
năng này. Khái niệm phiên và kết nối SSL liên quan đến nhiều tham số sử dụng
trong truyền thông hỗ trợ SSL giữa client và server. Trong quá trình thoả thuận
của giao thức handshake ngoài việc chọn các phương pháp mã hoá dữ liệu thì một
loạt các tham số của Session State cũng được chọn, Session State bao gồm:
 Session identifier: là định danh do server tạo ra và gán cho mỗi
phiên làm việc với một client nhất định,
 Peer certificate: chứng chỉ X.509 của nút còn lại của phiên,
 Phương pháp nén: xác định phương pháp nén dữ liệu trước khi mã
hoá,
 Mô tả thuật toán CipherSpec: xác định thuật toán để mã hoá dữ
liệu (ví dụ thuật toán DES) và thuật toán băm dữ liệu (ví dụ MD5)
sẽ sử dụng trong phiên,
 Master secret: là một số bí mật 48 byte được server và client dùng
chung,
 Cờ “is resumable”: cho biết có thể sử dụng phiên này để khởi tạo
các kết nối mới được không.
Ngoài ra còn có một số tham số khác:
 Số ngẫu nhiên của Server và client: dữ liệu ngẫu nhiên do cả client
và server sinh ra cho mỗi kết nối,
 Server write MAC secret: chìa khoá bí mật do server sử dụng để mã
hoá dữ liệu của server,
Trang 10
Đồ án môn học 3 Trang 11

ghi gửi cùng với MAC đó. MAC là kết quả của một của một hàm băm theo một
thuật toán băm được qui địng trước (ví dụ MD5 hoặc SHA-1).
- MAC được tính toán dựa trên việc áp dụng hàm băm trên các dữ liệu sau: khoá bí
mật, dữ liệu gốc, phần thông tin bổ xung, số thứ tự.
- Khoá bí mật ở đây có thể là khoá ghi MAC của client (client write MAC secret)
hoặc của server (server write MAC secret) tuỳ thuộc vào ai là người tạo gói tin.
Trang 11
Đồ án môn học 3 Trang 12
- Sau khi nhận được một gói tin thì bên nhận tự tính lại giá trị MAC và so sánh với
giá trị MAC chứa trong gói tin đó. Nếu hai giá trị MAC đó giống nhau có nghĩa là
dữ liệu không bị thay đổi trong quá trình truyền trên mạng. Độ dài của trường
MAC phụ thuộc vào phương pháp để tính ra nó.
- Tiếp theo, phần dữ liệu cộng với MAC sẽ được mã hoá sử dụng phương pháp mã
hoá (đối xứng) đã thoả thuận trước ví dụ DES hoặc triple DES. Như vậy là cả dữ
liệu và MAC đều được mã. Phần dữ liệu đã được mã hoá đó được gắn thêm
header bao gồm các trường sau:
 Kiểu nội dung (content type): xác định dữ liệu nào chứa trong gói tin để quyết
định xem giao thức nào ở lớp cao hơn sẽ chịu trách nhiệm xử lý dữ liệu của gói
tin đó. Các giá trị có thể của trường này là: change_cipher_spec, alert, handshake
và application_data tham chiếu đến các giao thức tương ứng ở mức cao hơn.
 Phiên bản chính (major version): phần chỉ số chính của phiên bản SSL đang sử
dụng.Ví dụ với SSL 3.0 thì giá trị trường này là 3.
 Phiên bản phụ (minor version): phần chỉ số phụ của phiên bản SSL đang sử dụng.
Ví dụ với SSL 3.0 thì giá trị trường này là 0.
- Sau khi tính toán xong các trường này, bản ghi đã được tạo xong và sẵn sàng để
gửi đến cho máy đích. Toàn bộ quá trình chuẩn bị bản ghi trước khi gửi được mô
tả trong hình 1.3.
Hình 1.3: Quá trình tạo một bản ghi của SSL Record Protocol
Trang 12
Đồ án môn học 3 Trang 13

2: S -> C: SERVERHELLO
[CERTIFICATE]
[SERVERKEYEXCHANGE]
[CERTIFICATEREQUEST]
SERVERHELLODONE
3: C -> [CERTIFICATE]
CLIENTKEYEXCHANGE
[CERTIFICATEVERIFY]
Trang 13
Đồ án môn học 3 Trang 14
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:
Trang 14
Đồ án môn học 3 Trang 15
 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

session tương ứng, server đáp ứng bằng cùng một giá trị như được cung cấp bởi
Trang 15
Đồ án môn học 3 Trang 16
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 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

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 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à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à
Trang 18
Đồ án môn học 3 Trang 19
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 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

diện trên Internet.HTTP là một giao thức ứng dụng của bộ giao thức TCP/IP (các
giao thức nền tảng cho Internet).
HTTPS là gì?
- HTTPS( Secure HTTP), là một sự kết hợp giữa giao thức HTTP và giao thức bảo
mật SSL hay TLS cho phép trao đổi thông tin một cách bảo mật trên Internet. Các
kết nối HTTPS thường được sử dụng cho các giao dịch thanh toán trên World
Wide Web và cho các giao dịch nhạy cảm trong các hệ thống thông tin công ty.
HTTPS được sử dụng trong nhiều tình huống, chẳng hạn như các trang đăng nhập
cho ngân hàng, các hình thức, ích đăng nhập công ty, và các ứng dụng khác, trong
đó dữ liệu cần phải được an toàn.HTTPS không nên nhầm lẫn với Secure HTTP
(S-HTTP) quy định trong RFC 2660.
1.2.2.Phân tích hoạt động của giao thức HTTPS
- Giao thức HTTPS sử dụng port 443, và cung cấp các dịch vụ hay đảm bảo tính
chất sau của thông tin:
Confidentiality: sử dụng phương thức encryption để đảm bảo rằng các thông
điệp được trao đổi giữa client và server không bị kẻ khác đọc được.
Integrity: sử dụng phương thức hashing để cả client và server đều có thể tin
tưởng rằng thông điệp mà chúng nhận được có không bị mất mát hay chỉnh sửa.
Authenticity: sử dụng digital certificate để giúp client có thể tin tưởng rằng
server/website mà họ đang truy cập thực sự là server/website mà họ mong muốn
vào, chứ không phải bị giả mạo.
Trang 20
Đồ án môn học 3 Trang 21
1.2.2.1. Sử dụng HTTPS như thế nào?
- Trước hết, muốn áp dụng HTTPS thì trong quá trình cấu hình Webserver, có thể
dễ dàng tự tạo ra một SSL certificate dành riêng cho website của mình và nó được
gọi là self-signed SSL certificate.
SSL certificate tự cấp này vẫn mang lại tính Confidentiality và Integrity cho quá
trình truyền thông giữa server và client. Nhưng rõ ràng là không đạt được
tính Authenticity bởi vì không có bên thứ 3 đáng tin cậy nào (hay CA) đứng ra

1. Client gửi request cho một secure page (có URL bắt đầu với https://)
2. Server gửi lại cho client certificate của nó.
3. Client gửi certificate này tới CA (mà được ghi trong certificate) để kiểm
chứng.
Giả sử certificate đã được xác thực và còn hạn sử dụng hoặc client vẫn cố tình
truy cập mặc dù Web browser đã cảnh báo rằng không thể tin cậy được
certificate này (do là dạng self-signed SSL certificate hoặc certificate hết hiệu
lực, thông tin trong certificate không đúng…) thì mới xảy ra bước 4 sau.
4. Client tự tạo ra ngẫu nhiên một symmetric encryption key, rồi sử dụng public
key (trong certificate) để mã hóa symmetric key này và gửi về cho server.
5. Server sử dụng private key (tương ứng với public key trong certificate ở trên)
để giải mã ra symmetric key ở trên.
6. Sau đó, cả server và client đều sử dụng symmetric key đó để mã hóa/giải mã
các thông điệp trong suốt phiên truyền thông.
Và tất nhiên, các symmetric key sẽ được tạo ra ngẫu nhiên và có thể khác
nhau trong mỗi phiên làm việc với server. Ngoài encryption thì cơ chế hashing
sẽ được sử dụng để đảm bảo tính Integrity cho các thông điệp được trao đổi.
1.2.3 SMTPS
Trang 22
Đồ án môn học 3 Trang 23
1.2.3.1 Giao thức SMTP và SMTPS
SMTP là gì?
- SMTP (tiếng Anh: Simple Mail Transfer Protocol - giao thức truyền tải
thư tín đơn giản) là một chuẩn truyền tải thư điện tử qua mạng Internet.
SMTP được định nghĩa trong bản RFC 821 (STD 10) và được chỉnh lý
bằng bản RFC 1123 (STD 3). Giao thức hiện dùng được là ESMTP
(extended SMTP - SMTP mở rộng), được định nghĩa trong bản RFC 2821.
Lịch sử
o SMTP là một giao thức dùng nền văn bản và tương đối đơn giản. Trước
khi một thông điệp được gửi, người ta có thể định vị một hoặc nhiều địa