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ộ
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.5 MB, 66 trang )
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 :
………………………………………………………………………………………………
………………………………………………………………………………………………
3. Người hướng dẫn :
………………………………………………………………………………………………
…………………………………………
4. Những ưu điểm của Đồ án :
…………………………………………………………………………………………………
…
……………………………………………………………………………………………………
……………………………………………………………………………………………………
……………………………………………………………………………………………………
……………………………………………………………………………………………………
Những thiếu sót của Đồ án:
……………………………………………………………………………………………………
……………………………………………………………………………………………………
……………………………………………………………………………………………………
……………………………………………………………………………………………………
……………………………………………………………………………………………………
5. Đề nghị : Được bảo vệ: Bổ sung để được bảo vệ: Không được bảo vệ:
6. Các câu hỏi sinh viên phải trả lời trước Tổ chấm ĐAMH:
a)……………………………………………………………………………………………
………………………………………………………………………………………………
b)……………………………………………………………………………………………
……………………………………………………………………………………………………
c)
……………………………………………………………………………………………………
……………………………………………………….…………………
Đánh giá Điểm (Số và chữ):………………………………
CHỮ KÝ và HỌ TÊN
Đồ án môn học 3 Trang 1
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
Phần B Nội dung
Chương 1: SSL và ứng dụng 5
1.1. Tổng quan về Secure Socket Layer 5
1.2. HTTPS 21
1.3. SMTPS 24
1.4. POPS 28
Chương 2: Ứng dụng SSL cho web và mail server trong mạng nội bộ 31
2.1. Mô hình mạng 31
2.2. Các bước thực hiện triển khai SSL 58
Chương 3: Kết luận 63
3.1. Kết quả đạt được 63
3.2. Hạn chế 63
3.3. Hướng phát triển 63
Phần C Tài liệu tham khảo
1. Tài liệu tham khảo 65
2. Lời kết 65
Trang 3
Đồ án môn học 3 Trang 4
Phần B
NỘI DUNG
Trang 4
Đồ án môn học 3 Trang 5
Chương 1:SSL VÀ ỨNG DỤNG
1.1.Tổng quan về Secure Socket Layer
1.1.1.Mở đầu
– Bảo mật cho dữ liệu truyền trên Internet ngày càng trở nên cần thiết do số lượng
cũng như mức độ quan trọng của các dữ liệu này ngày càng cao. Ngày nay, người
dùng Internet trao đổi rất nhiều loại thông tin trên mạng từ trao đổi thư điện tử
thông thường đến các thông tin chi tiết trong thẻ tín dụng của mình, do đó họ
muốn những dữ liệu đó phải được bảo mật khi truyền trên mạng công cộng.
– Để 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.
Hình 1.2 : Cấu trúc SSL
Những mục đích chính của việc phát triển SSL là:
• Xác thực server và client với nhau: SSL hỗ trợ sử dụng các kỹ thuật mã
hoá khoá chuẩn (mã hoá sử dụng khoá công khai) để xác thực các đối tác
truyền thông với nhau. Hầu hết các ứng dụng hiện nay xác thực các client
bằng cách sử dụng chứng chỉ số, SSL cũng có thể sử dụng phương pháp
này để xác thực client.
• Đảm bảo toàn vẹn dữ liệu: trong một phiên làm việc, dữ liệu không thể bị
làm hỏng dù vô tình hay cố ý.
Trang 6
Đồ án môn học 3 Trang 7
• Bảo vệ tính riêng tư: dữ liệu trao đổi giữa client và server phải được bảo
vệ, tránh bị đánh cắp trên đường truyền và chỉ có đúng người nhận mới có
thể đọc được các dữ liệu đó. Các dữ liệu được bảo vệ bao gồm các những
dữ liệu liên quan đến chính hoạt động giao thức (các thông tin trao đổi
trong quá trình thiết lập phiên làm việc SSL) và các dữ liệu thực trao đổi
trong phiên làm việc.
– Thực tế SSL không phải là một giao thức đơn mà là một bộ các giao thức, có thể
được chia làm 2 lớp:
1. Giao thức đảm bảo sự an toàn và toàn vẹn dữ liệu: lớp này chỉ có một
giao thức là SSL Record Protocol
2. Các giao thức thiết kế để thiết lập kết nối SSL: lớp này gồm có 3 giao
thức: SSL Handshake Protocol, SSL ChangeCipherSpecProtocol và
SSL Alert Protocol.
– SSL sử dụng các giao thức này để thực hiện các nhiệm vụ được đề cập ở trên.
SSL Record Protocol chịu trách nhiệm mã hoá và đảm bảo toàn vẹn dữ liệu. Như
ta thấy trong hình 2, giao thức này còn chịu trách nhiệm đóng gói các dữ liệu của
các giao thức SSL khác tức là cũng liên quan đến các tác vụ kiểm tra dữ liệu SSL.
Ba giao thức còn lại chịu trách nhiệm quản lý các phiên, quản lý các tham số mã
hoá và truyền các thông điệp SSL giữa client và server. Trước khi đi vào chi tiết
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
SSL/TLS được tóm tắt trong bảng 1.1 và được minh họa một phần trong hình 2.
Ngày nay, “S” chỉ định việc sử dụng SSL được thêm (hậu tố) nhất quán vào các
từ ghép của các giao thức ứng dụng tương ứng (trong một số thuật ngữ ban đầu, S
được sử dụng và được thêm tiền tố một cách không nhất quán và một số từ ghép)
Bảng1.1: Các số cổng được gán cho các giao thức ứng dụng chạy trên TLS/SSL.
– Nói chung, một session SSL có trạng thái và giao thức SSL phải khởi tạo và duy
trì thông tin trạng thái ở một trong hai phía của session. Các phần tử thông tin
trạng thái session tương ứng bao gồm một session ID, một chứng nhận ngang
hàng, một phương pháp nén, một thông số mật mã, một khóa mật chính và một cờ
vốn chỉ định việc session có thể tiếp tục lại hay không, được tóm tắt trong bảng
1.2. Một session SSL có thể được sử dụng trong một số kết nối và các thành phần
thông tin trạng thái nối kết tương ứng được tóm tắt trong bảng 1.3. Chúng bao
gồm các tham số mật mã, chẳng hạn như các chuỗi byte ngẫu nhiên server và
client, các khóa mật MAC ghi server và client, các khóa ghi server và client, một
vector khởi tạo và một số chuỗi. Ở trong hai trường hợp, điều quan trọng cần lưu
ý là các phía giao tiếp phải sử dụng nhiều session SSL đồng thời và các session
có nhiều nối kết đồng thời.
Trang 8
Đồ án môn học 3 Trang 9
–
Bảng 1.2 Các thành phần thông tin trạng thái Session SSL
Bảng 1.3 Các thành phần thông tin trạng thái nối kết SSL
1.1.3.Phiên SSL và kết nối SSL
– Các khái niệm đề cập ở trên là các khái niệm cơ bản của công nghệ SSL. Ngoài ra
còn có rất nhiều thuộc tính khác của SSL mà chúng ta sẽ xem xét ở đây:
Trang 9
Đồ án môn học 3 Trang 10
• connection (kết nối): là một liên kết client/server logic với những kiểu dịch vụ
thích hợp. SSL connection là một kết nối điểm nối điểm giữa 2 nút mạng.
• session (phiên): là một sự kết hợp giữa một client và một server xác định bằng
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
Client write MAC secret: chìa khoá bí mật do client sử dụng để mã
hoá dữ liệu của client.
Server write key: chìa khoá mà server dùng để mã hoá và client
dùng để giải mã dữ liệu.
Client write key: chìa khoá mà client dùng để mã hoá và server
dùng để giải mã dữ liệu.
Sequence number (số thứ tự): server và client quản lý một cách
riêng rẽ các số thứ tự để đánh số các thông điệp gửi và nhận cho
mỗi kết nối.
1.4.SSL Record Protocol
– SSL Record Protocol sử dụng để trao đổi tất cả các kiểu dữ liệu trong một phiên –
bao gồm các thông điệp, dữ liệu của các giao thức SSL khác và dữ liệu của ứng
dụng.
– SSL Record Protocol liên quan đến việc bảo mật và đảm bảo toàn vẹn dữ liệu.
Mục đích của SSR Record Protocol là thu nhận những thông điệp mà ứng dụng
chuẩn bị gửi, phân mảnh dữ liệu cần truyền, đóng gói, bổ xung header tạo thành
một đối tượng gọi là bản ghi (record), bản ghi đó được mã hoá và có thể truyền
bằng giao thức TCP.
– Bước đầu tiên của quá trình chuẩn bị truyền dữ liệu là phân mảnh dữ liệu, tức là
chia nhỏ dòng dữ liệu thành các mảnh kích thước 16KB (hoặc nhỏ hơn). Những
mảnh dữ liệu này sau đó có thể được nén trước khi truyền. Sau đó bắt đầu quá
trình tạo các bản ghi cho mỗi đơn vị dữ liệu bằng cách bổ xung thêm header, một
số byte cho đủ kích thước qui định của bản ghi nếu kích thước bản ghi chưa đủ và
cuối cùng là phần MAC. MAC (Message Authentication Code) là mã xác thực
thông điệp sử dụng để khi phát dữ liệu trong các phiên SSL.
– Phần header của mỗi bản ghi chứa 2 thông tin quan trọng đó là độ dài của bản ghi
và độ dài của khối dữ liệu thêm vào phần dữ liệu gốc. Phần dữ liệu của một bản
ghi gồm:
• dữ liệu gốc,các byte bổ xung cho đủ kích thước gói tin qui định,giá trị MAC
– MAC được sử dụng để kiểm chứng sự toàn vẹn của thông điệp chứa trong bản
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
1.1.5.Alert Protocol
– Alert Protocol được các bên sử dụng để mang các thông điệp của phiên liên quan
tới việc trao đổi dữ liệu và hoạt động của các giao thức. Mỗi thông điệp của giao
thức này gồm 2 byte. Byte thứ nhất chứa một trong hai giá trị là warning (1) và
fatal (2) xác định tính nghiêm trọng của thông điệp. Khi một trong 2 bên gửi
thông điệp có giá trị bít đầu tiên là fatal (2) thì phiên làm việc giữa 2 bên sẽ kết
thúc ngay lập tức. Byte tiếp theo của thông điệp chứa mã lỗi xảy ra trong phiên
giao dịch SSL.
1.1.6.Change CipherSpec Protocol
– Đây là giao thức SSL đơn giản nhất. Nó chỉ chứa một thông điệp mang giá trị 1.
Mục đích duy nhất của thông điệp này là làm chuyển trạng thái của một phiên từ
“đang chờ” (pending) sang “bền vững” (fixed). Ví dụ khi 2 bên qui ước bộ giao
thức nào sẽ sử dụng. Cả client và server đều phải gửi thông điệp loại này cho bên
đối tác, sau khi đã trao đổi xong thì coi như hai bên đã đồng ý với nhau.
1.1.7.Handshake Protocol
– SSL Handshake Protocol là giao thức con SSL chính được xếp lớp trên SSL
Record Protocol.Kết quả, các thông báo thiết lập quan hệ SSL được cung cấp cho
lớp bản ghi SSL nơi chúng được bao bọc trong một hoặc nhiều bản ghi SSL vốn
được xử lý và được chuyển như được xác định bởi phương pháp nén và thông số
mật mã của session SSL hiện hành và các khóa mật mã của nối kết SSL tương
ứng. Mục đích của SSL Handshake Protocol là yêu cầu một client và server thiết
lập và duy trì thông tin trạng thái vốn được sử dụng để bảo vệ các cuộc liên lạc.
Cụ thể hơn, giao thức phải yêu cầu client và server chấp thuận một phiên bản giao
thức SSL chung, chọn phương thức nén và thông số mật mã, tùy ý xác thực nhau
và tạo một khóa mật chính mà từ đó các khóa session khác nhau dành cho việc
xác thực và mã hóa thông báo có thể được dẫn xuất từ đó.
– Tóm lại, việc thực thi SSL Handshake Protocol giữa một client C và một server S
có thể được tóm tắt như sau (các thông báo được đặt trong các dấu ngoặc vuông
thì tùy ý):
1: C -> S: CLIENTHELLO
2: S -> C: SERVERHELLO
[CERTIFICATE]
[SERVERKEYEXCHANGE]
[CERTIFICATEREQUEST]
SERVERHELLODONE
3: C -> [CERTIFICATE]
CLIENTKEYEXCHANGE
[CERTIFICATEVERIFY]
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
hiện không tồn tại hoặc nếu client muốn tạo các tham số bảo mật mới. Ở một
trong hai trường hợp, một trường session identity không rỗng là xác định một
session SSL hiện có giữa client và server (nghĩa là một session có các tham số
bảo mật mà client muốn sử dụng lại.). Định danh session có thể bắt nguồn từ một
nối kết trước đó, nối kết này hoặc một nối kết đang hoạt động. Cũng chú ý rằng
danh sách các bộ mật mã được hỗ trợ, được chuyển từ client đến server
trong thông báo CLIENTHELLO, chứa các tổ hợp thuật toán mật mã được hỗ
trợ bởi client theo thứ tự ưu tiêm. Mỗi bộ mật mã xác định một thuật toán trao đổi
khóa và một thông báo mật mã. Server sẽ chọn một bộ mật mã hoặc nếu các lựa
chọn có thể chấp nhận được không được trình bầy, trả về một thông báo lỗi và
đóng nối kết một cách phù hợp. Sau khi đã gởi thông báo CLIENTHELLO,
client đợi một thông báo SERVERHELLO. Bất kỳ thông báo khác được trả về
bởi server ngoại trừ một thông báo HELLOREQUEST được xem như là một lỗi
vào thời điểm này.
– Ở bước 2, server xử lý thông báo CLIENTHELLO và đáp ứng bằng một thông
báo lỗi hoặc thông báo SERVERHELLO.Tương tự như thông báo
CLIENTHELLO, thông báo SERVERHELLO có các trường sau đây:
– Một số phiên bản server chứa phiên bản thấp hơn của phiên bản được đề
nghị bởi client trong thông báo CLIENTHELLO và được hỗ trợ cao nhất bởi
Server.
– Một cấu trúc ngẫu nhiên do server tạo ra cũng gồm một tem thời gian 32bit có
dạng UNIX chuẩn và một giá trị 28bit được tạo ra bởi một bộ tạo số ngẫu nhiên.
– Một định danh session tương ứng với nối kết này.
– Một bộ mật mã được chọn từ bởi server từ danh sách các bộ mật mã được hỗ trợ
bởi client.
– Một phương pháp nén được chọn bởi server từ danh sách các thuật toán nén được
hỗ trợ bởi client.
– Nếu định danh session trong thông báo CLIENTHELLO không rỗng, server tìm
trong cache session của nó nhằm tìm ra một mục tương hợp. Nếu mục tương hợp
được tìm thấy và server muốn thiết lập nối kết mới bằng cách sử dụng trạng thái
session tương ứng, server đáp ứng bằng cùng một giá trị như được cung cấp bởi
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
vào token FORITEZZA (KEA). Rõ ràng, thông báo này không được yêu cầu nếu
chứng nhận site gồm một khóa chung RSA vốn có thể được sử dụng trong việc
mã hóa. Ngoài ra, một server không nặc danh có thể tùy ý yêu cầu một chứng
nhận cá nhân để xác thực client. Do đó, nó gởi một thông báo
CERTIFICATERequest đến client. Thông báo này chứa một danh sách các loại
chứng nhận được yêu cầu, được phân loại theo thứ tự ưu tiên của server cũng như
một danh sách các tên được phân biệt cho các CA có thể chấp nhận. Ở
cuối bước 2, server gởi một thông báo SERVERHELLODone đến client để chỉ
định sự kết thúc SERVERHELLO và các thông báo đi kèm.
– Sau khi nhận SERVERHELLO và các thông báo đi kèm, client xác nhận rằng
chứng nhận site server (nếu được cung cấp) là hợp lệ và kiểm tra nhằm bảo đảm
rằng các thông số bảo mật được cung cấp trong thông báo SERVERHELLO có
thể được chấp nhận. Nếu server yêu cầu sự xác thực client, client gởi một thông
báo CERTIFICATE vốn chứa một chứng nhận cá nhân cho khóa chung của
người dùng đến server ở bước 3. Tiếp theo, client gởi một thông báo
Trang 16
Đồ án môn học 3 Trang 17
CLIENTKEYEXCHANGE có dạng phụ thuộc vào thuật toán cho mỗi khóa được
chọn bởi server:
– Nếu RSA được sử dụng cho việc xác thực server và trao đổi khóa, client tạo một
khóa mật tiền chính 48 byte, mã hóa nó bằng khóa chung được tìm thấy trong
chứng nhận site hoặc khóa RSA tạm thời từ thông báo
SERVERKEYEXCHANGE và gởi kết quả trở về server trong thông báo
CLIENTKEYEXCHANGE. Lần lượt server sử dụng khóa riêng tương ứng để
giải mã khóa mật chính.
– Nếu các token FORTEZZA được sử dụng để trao đổi khóa, client dẫn xuất một
khóa mã hóa token (TEK) bằng cách sử dụng KEA. Phép tình KEA củ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á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
Trang 17
Đồ án môn học 3 Trang 18
và tổng cộng sáu thông báo được yêu cầu. Các dòng thông báo tương ứng có thể
được tóm tắt như sau:
1: C -> S: CLIENTHELLO
2: S -> C: SERVERHELLO
CHANECIPHERSPEC
FINISHED
3: S ->C: CHANGECIPHERSPEC
FINISHED
– Ở bước 1, client gởi một thông báo CLIENTHELLO đến server vốn có một định
danh session cần được tiếp tục lại. Lần lượt server kiểm tra cache session của nó
để tìm một mục tương hợp. Nếu một mục tương hợp được tìm thấy, server muốn
tiếp tục lại nối kết bên dưới trạng thái session đã xác định, nó trả về một thông
báo SERVERHELLO với cùng một định danh session ở bước 2. Vào thời
điểm này, cả client lẫn server phải gởi các thông báo
CHANGECIPHERSPEC và FINISHED đến nhau ở bước 2 và 3. Một khi việc
tái thiết lập session hoàn tất, client và server có thể bắt đầu trao đổi dữ liệu ứng
dụng.
1.1.8.Phân tích bảo mật
– Sự phân tích bảo mật toàn diện về SSL 3.0 đã được thực hiện bởi Bruce
Scheneier và David Wagner vào năm 1996. Ngoại trừ một số khiếm khuyết nhỏ
và những tính năng gây lo lắng vốn có thể được sữa chữa dễ dàng mà không cần
tu sửa cấu trúc cơ bản của giao thức SSL, họ không tìm thấy vấn đề điểm yếu
hoặc bảo mật nghiêm trọng trong việc phân tích của họ. Kết quả, họ kết luận
rằng giao thức SSL cung cấp sự bảo mật hoàn hảo ngăn việc nghe lén và những
cuộc tấn công thụ động khác, và người thực thi giao thức này sẽ ý thức đến
một số cuộc tấn công chủ động tinh vi.
– Tuy nhiên, một vài tháng sau, Daniel Bleichenbacher từ Bell Laboratoires đã tìm
thấy một cuộc tấn công text mật mã được chọn thích ứng nhắm các giao thức dựa
vào tiêu chuẩn mà khóa chung (PKCS) #1. Cuộc tấn công đã được xuất bản vào
năm 1998. Tóm lại, một hoạt động khóa riêng RSA (một hoạt động giải mã hoặc
chữ ký kỹ thuật số có thể được thực hiện nếu kẻ tấn công truy cập một oracle mà
đối với bất kỳ text mật mã được chon, trả về chỉ 1 bit cho biết text mật mã có
tương ứng với một số khối dữ liệu không được biết được mã hóa bằng cách sử
dụng PKCS #1 hay không.)
– Để tìm hiểu cuộc tấn công Bleichenbacher, cần phải xem PKCS #1. Thực tế, có
ba dạng khối được xác định trong PKCS #1: các loại khối 0 và 1 được sử dụng
cho các chữ ký kỹ thuật số RSA và loại khối 2 được sử dụng cho việc mã hóa
RSA. Các phần thảo luận trước, hãy nhớ rằng nếu thuật toán RSA được sử dụng
cho việc xác thực server và trao đổi khóa, client tạo ngẫu nhiên một khóa mật
chính 46 byte, thêm tiền tố hai byte 03 (số phiên bản giao thức SSL) và 00 vào
khóa mật chính, mã hóa kết quả bằng cách sử dụng khóa chung của server và
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
đã cho thấy thường giữa 300.000 và 2 triệu text mật mã được chọn được yêu cầu
để thực sự thực hiện hoạt động (giải mã hoặc chữ ký kỹ thuật số). Để làm cho
mọi thứ trở nên tệ hơn, cuộc tấn công có thể được thực hiện trên một server SSL
vốn có sẵn on-line (vì nó phải hoạt động như một oracle). Từ quan điểm của kẻ
tấn công, có thể khó gửi số lượng lớn text mật mã được chọn này đến server SSL
mà không làm cho nhà quản trị server trở lên nghi ngờ.
– Có một số khả năng để ngăn ngừa sự tấn công Bleichenbacher. Trên hết, server
không cần đáp ứng lại một thông báo lỗi sau khi đã nhận một thông báo
CLIENTKEYEXCHANGE vốn không phù hợp với PKCS #1. Một khả năng khác
là thay đổi dạng khối PKCS #1 để mã hóa và loại bỏ các byte 00 và 02 dẫn đầu
cũng như các byte 00, 03 và 00 ở giữa thông báo (như được minh họa trong hình
6.3). Sau cùng, một khả năng khác là sử dụng các sơ đồ mã hóa có khả năng nhận
biết text thuần túy chẳng hạn như các sơ đồ được đề xuất bởi Mihir Bellar và
Philip Rogaway và bất kỳ hệ thống mật mã khóa chng khác vốn có thể bảo vệ
ngăn ngừa các cuộc tấn công text mật mã được chọn thích ứng.
Trang 19
Đồ án môn học 3 Trang 20
1.2.HTTPS
1.2.1.Giao thức HTTP và HTTPS
HTTP là gì?
– HTTP là chữ viết tắt từ HyperText Transfer Protocol (giao thức truyền tải siêu
văn bản). Nó là giao thức cơ bản mà World Wide Web sử dụng. HTTP xác định
cách các thông điệp (các file văn bản, hình ảnh đồ hoạ, âm thanh, video, và các
file multimedia khác) được định dạng và truyền tải ra sao, và những hành động
nào mà các Web server (máy chủ Web) và các trình duyệt Web (browser) phải
làm để đáp ứng các lệnh rất đa dạng. Chẳng hạn, khi bạn gõ một địa chỉ Web
URL vào trình duyệt Web, một lệnh HTTP sẽ được gửi tới Web server để ra lệnh
và hướng dẫn nó tìm đúng trang Web được yêu cầu và kéo về mở trên trình duyệt
Web. Nói nôm na hơn, HTTP là giao thức truyền tải các file từ một Web server
vào một trình duyệt Web để người dùng có thể xem một trang Web đang hiện
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
kiểm chứng sự tính xác thực của certificate tự gán này. Điều này cũng giống như
việc một người tự làm chứng minh nhân dân (CMND) cho mình rồi tự họ ký tên,
đóng dấu luôn vậy!
Vì vậy, đối với các website quan trọng như E-Commerce, Online Payment, Web
Mail,… thì họ sẽ mua một SSL certificate từ một Trusted Root CA nổi tiếng như
VeriSign, Thawte, và ít tên tuổi hơn thì có GoDaddy, DynDNS… Các CA có 2
nhiệm vụ chính sau:
– Cấp phát và quản lý SSL certificate cho server/website.
– Xác thực sự tồn tại và tính hiệu lực của SSL certificate mà Web client gửi tới
cho nó.
Thực chất thì SSL certificate cũng là một loại digitial certificate (một loại file trên
máy tính). Vì giao thức HTTPS có dính tới giao thức SSL nên người ta mới đặt
tên cho nó là SSL certificate để phân biệt với các loại digital certificate khác
như Personal Certificate, Server Certificate, Software Publisher Certificate,
Certificate Authority Certificate.
Dưới đây là một số thông tin quan trọng được chứa trong SSL certificate mà bất
cứ client nào cũng có thể xem được bằng cách click vào biểu tượng padlock trên
thanh Address của Web browser:
– Thông tin về owner của certificate (như tên tổ chức, tên cá nhân hoặc domain
của website…).
– Tên và digital signature của CA cấp certificate.
– Khoảng thời gian mà certificate còn hiệu lực sử dụng.
– Public key của server/website. Còn private key được lưu trữ trên chính server
(không có trong certificate) và tuyệt đối không thể để lộ cho bất cứ client nào.
– Một số thông tin phụ khác như: loại SSL certificate, các thuật toán dùng để
encryption và hashing, chiều dài (tính bằng bit) của key, cơ chế trao đổi key (như
Trang 21
Đồ án môn học 3 Trang 22
RSA, DSA…).
1.2.2.2.Quá trình giao tiếp giữa client và server thông qua HTTPS
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
chỉ nhận cho thông điệp – những địa chỉ này thường được kiểm tra về sự
tồn tại trung thực của chúng). Việc kiểm thử một trình chủ SMTP là một
việc tương đối dễ dàng, dùng chương trình ứng dụng “telnet.
o SMTP dùng cổng 25 của giao thức TCP. Để xác định trình chủ SMTP của
một tên miền nào đấy (domain name), người ta dùng một mẫu tin MX
(Mail eXchange – Trao đổi thư) của DNS (Domain Name System – Hệ
thống tên miền).
o SMTP bắt đầu được sử dụng rộng rãi vào những năm đầu thập niên kỷ
1980. Tại thời điểm đó, SMTP chỉ là một phần mềm bổ sung của bộ trình
ứng dụng đồng giao thức UUCP (Unix to Unix CoPy – Sao chép từ máy
Unix sang máy Unix)nhưng tiện lợi hơn trong việc truyền tải thư điện tử
giữa các máy vi tính – những máy này thỉnh thoảng mới lại được kết nối
với nhau một lần, để truyền thông dữ liệu. Thực ra, SMTP sẽ làm việc tốt
hơn nếu các máy gửi và máy nhận được kết nối liên tục.Sendmail là một
trong những phần mềm đặc vụ truyền tải thư tín (mail transfer agent) đầu
tiên (nếu không phải là cái trước tiên nhất) thực thi giao thức SMTP. Tính
đến năm 2001, người ta đã thấy có ít nhất là 50 chương trình ứng dụng
thực thi giao thức SMTP, bao gồm cả trình khách (phần mềm dùng để gửi
thông điệp) và trình chủ (phần mềm dùng để nhận thông điệp). Một số
trình chủ SMTP nổi tiếng có thể liệt kê bao gồm: exim, Postfix, qmail, và
Microsoft Exchange Server.
o Do thiết kế của giao thức dùng dạng thức văn bản thường của bộ mã
ASCII, khi bản thiết kế được khởi công, chức năng của SMTP giải quyết
tập tin có dạng thức nhi phân rất kém. Những tiêu chuẩn như MIME đã
được xây dựng để mã hóa những tập tin nhị phân, cho phép chúng được
truyền tải dùng giao thức SMTP. Hiện nay, phần lớn các trình chủ SMTP
hỗ trở phần mở rộng 8BITMIME của SMTP, cho phép các tập tin ở dạng
thức nhị phân được truyền thông qua đường dây, dễ như việc truyền tải
văn bản thường vậy.
Trang 23
3. Người hướng dẫn : … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … 4. Những ưu điểm của Đồ án : … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … Những thiếu sót của Đồ án : … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … 5. Đề nghị : Được bảo vệ : Bổ sung để được bảo vệ : Không được bảo vệ : 6. Các câu hỏi sinh viên phải vấn đáp trước Tổ chấm ĐAMH : a ) … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … b ) … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … c ) … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … … …. … … … … … … … Đánh giá Điểm ( Số và chữ ) : … … … … … … … … … … … … CHỮ KÝ và HỌ TÊNĐồ án môn học 3 Trang 1P hần AGIỚI THIỆULỜI NÓI ĐẦUTrang 1 Đồ án môn học 3 Trang 2L ời tiên phong nhóm thực thi đề tài xin cảm ơn thầy cô giáo chuyên ngành điệntử, cảm ơn thầy Lê Minh đã hướng dẫn tận tình nhóm triển khai đề tài trong quá trìnhthực hiện đồ án này. Trong những thanh toán giao dịch điện tử trên mạng và trong những thanh toán giao dịch thanh toán giao dịch trựctuyến, thông tin / tài liệu trên thiên nhiên và môi trường mạng Internet không bảo đảm an toàn thường được bảođảm bởi chính sách bảo mật thông tin triển khai trên tầng vận tải đường bộ có tên Lớp cổng bảo mật thông tin SSL ( Secure Socket Layer ) – một giải pháp kỹ thuật lúc bấy giờ được sử dụng khá phổ biếntrong những hệ quản lý mạng máy tính trên Internet. SSL là giao thức đa mục tiêu đượcthiết kế để tạo ra những tiếp xúc giữa hai chương trình ứng dụng trên một cổng định trước ( socket 443 ) nhằm mục đích mã hoá hàng loạt thông tin đi / đến, được sử dụng trong thanh toán giao dịch điệntử như truyền số liệu thẻ tín dụng, mật khẩu, số bí hiểm cá thể ( PIN ) trên Internet. Giaothức SSL được hình thành và tăng trưởng tiên phong nǎm 1994 bởi nhóm nghiên cứuNetscape dẫn dắt bởi Elgammal, và ngày này đã trở thành chuẩn bảo mật thông tin thực hành thực tế trênmạng Internet. Phiên bản SSL lúc bấy giờ là 3.0 và vẫn đang liên tục được bổ trợ và hoànthiện. Do kỹ năng và kiến thức còn hạn hẹp và trình độ về trình độ 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ự góp phần quan điểm và chỉ bảonhiệt tình từ phía những thầy cô để đề tài được hoàn thành xong hơn. Tp. HCM, Tháng 1 năm 2012M ỤC LỤCPhần A GIỚI THIỆU TrangTrang 2 Đồ án môn học 3 Trang 3L ời nói đầu 2M ục lục 3P hần B Nội dungChương 1 : SSL và ứng dụng 51.1. Tổng quan về Secure Socket Layer 51.2. HTTPS 211.3. SMTPS 241.4. POPS 28C hương 2 : Ứng dụng SSL cho web và mail server trong mạng nội bộ 312.1. Mô hình mạng 312.2. Các bước thực thi tiến hành SSL 58C hương 3 : Kết luận 633.1. Kết quả đạt được 633.2. Hạn chế 633.3. Hướng tăng trưởng 63P hần C Tài liệu tham khảo1. Tài liệu tìm hiểu thêm 652. Lời kết 65T rang 3 Đồ án môn học 3 Trang 4P hần BNỘI DUNGTrang 4 Đồ án môn học 3 Trang 5C hương 1 : SSL VÀ ỨNG DỤNG1. 1. Tổng quan về Secure Socket Layer1. 1.1. Mở đầu – Bảo mật cho tài liệu truyền trên Internet ngày càng trở nên thiết yếu do số lượngcũng như mức độ quan trọng của những tài liệu này ngày càng cao. Ngày nay, ngườidùng Internet trao đổi rất nhiều loại thông tin trên mạng từ trao đổi thư điện tửthông thường đến những thông tin cụ thể trong thẻ tín dụng thanh toán của mình, do đó họmuốn những tài liệu đó phải được bảo mật thông tin khi truyền trên mạng công cộng. – Để làm được điều này người ta đã ứng dụng giao thức SSL để bảo vệ những dữ liệutrong quy trình trao đổi giữa tổng thể những dịch vụ mạng sử dụng TCP / IP để hỗ trợcác tác vụ truyền thông online mạng giữa sever và máy khách. – Giao thức SSL tiên phong do Netscape tăng trưởng, mục tiêu để bảo mật thông tin dữ liệugửi / nhận trên Internet của những giao thức thuộc lớp ứng dụng như HTTP, LDAPhay POP3. SSL sử dụng giao thức TCP để phân phối những liên kết bền vững và kiên cố, bảomật và được xác nhận giữa những điểm cuối với nhau ( ví dụ như giữa client vàserver ). Mặc dù hoàn toàn có thể sử dụng SSL để bảo vệ tài liệu tương quan đến bất kể dịchvụ nào, nhưng SSL hầu hết được dùng trong những ứng dụng HTTP ( server vàclient ). Ngày nay hầu hết những HTTP server đều tương hỗ những phiên SSL, ở phíaclient những trình duyệt Internet Explorer và Netscape Navigator đều tương hỗ SSL.Hình 1.1 : SSL giữa tầng ứng dụng và tầng TCP / IP1. 1.2. Nhiệm vụ và cấu trúc của SSLTrang 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ấutrúc SSL và giao thức SSL ). Theo hình này, SSL ám chỉ một lớp ( bảo mật thông tin ) trunggian giữa lớp luâ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ụ luân chuyển xu thế nối kết và đángtin cậy, ví dụ điển hình như được phân phối bởi TCP. Về năng lực, nó hoàn toàn có thể cung cấpcác dịch vụ bảo mật thông tin cho những giao thức ứng dụng tùy ý dựa vào TCP chứ khôngchỉ HTTP. Thực tế, một ưu điểm chính của những giao thức bảo mật thông tin lớp luâ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 ứngdụng theo nghĩa là chúng hoàn toàn có thể được sử dụng để bảo vệ bất kể giao thức ứngdụ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 hoàn toàn 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 những từ ghép giao thức tương ứng chỉ định việc sửdụng SSL ). Tuy nhiên, chú ý quan tâm rằng SSL có một khuynh hướng client-server mạnh mẽvà thật sự không cung ứng những nhu yếu của những giao thức ứng dụng ngang hàng. Hình 1.2 : Cấu trúc SSLNhững mục tiêu chính của việc tăng trưởng SSL là : • Xác thực server và client với nhau : SSL tương hỗ sử dụng những kỹ thuật mãhoá khoá chuẩn ( mã hoá sử dụng khoá công khai minh bạch ) để xác nhận những đối táctruyền thông với nhau. Hầu hết những ứng dụng lúc bấy giờ xác nhận những clientbằng cách sử dụng chứng chỉ số, SSL cũng hoàn toàn có thể sử dụng phương phápnày để xác nhận client. • Đảm bảo toàn vẹn tài liệu : trong một phiên thao tác, tài liệu không hề bịlàm hỏng dù vô tình hay cố ý. Trang 6 Đồ án môn học 3 Trang 7 • Bảo vệ tính riêng tư : tài liệu trao đổi giữa client và server phải được bảovệ, tránh bị đánh cắp trên đường truyền và chỉ có đúng người nhận mới cóthể đọc được những tài liệu đó. Các tài liệu được bảo vệ gồm có những nhữngdữ liệu tương quan đến chính hoạt động giải trí giao thức ( những thông tin trao đổitrong quy trình thiết lập phiên thao tác SSL ) và những tài liệu thực trao đổitrong phiên thao tác. – Thực tế SSL không phải là một giao thức đơn mà là một bộ những giao thức, có thểđược chia làm 2 lớp : 1. Giao thức bảo vệ sự bảo đảm an toàn và toàn vẹn tài liệu : lớp này chỉ có mộtgiao thức là SSL Record Protocol2. Các giao thức phong cách thiết kế để thiết lập liên kết SSL : lớp này gồm có 3 giaothức : SSL Handshake Protocol, SSL ChangeCipherSpecProtocol vàSSL Alert Protocol. – SSL sử dụng những giao thức này để triển khai những trách nhiệm được đề cập ở trên. SSL Record Protocol chịu nghĩa vụ và trách nhiệm mã hoá và bảo vệ toàn vẹn tài liệu. Nhưta thấy trong hình 2, giao thức này còn chịu nghĩa vụ và trách nhiệm đóng gói những tài liệu củacác giao thức SSL khác tức là cũng tương quan đến những tác vụ kiểm tra tài liệu SSL.Ba giao thức còn lại chịu nghĩa vụ và trách nhiệm quản trị những phiên, quản trị những tham số mãhoá và truyền những thông điệp SSL giữa client và server. Trước khi đi vào chi tiếtvề vai trò của từng giao thức tất cả chúng ta hãy xem xét hai khái niệm mang tính nềntảng tương 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 đangsử dụng SSL. Nói chung, có ba năng lực để xử lý yếu tố này : 1. Sử dụng những số cổng chuyên sử dụng được dành riêng bởi Internet AsignedNumbers Authority ( IANA ). Trong trường hợp này, một số ít cổng riêng không liên quan gì đến nhau 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áctùy chọn bảo mật thông tin như thể một phần của giao thức ứng dụng ( giờ đây được chỉnhsử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ảomật, ví dụ điển hình như SSL trong suốt quá trình thiết lập nối kết TCP thường thì. – Sự thương lượng dành riêng cho ứng dụng của những tùy chọn bảo mật thông tin ( nghĩa làkhả năng thứ hai ) có khuyết điểm là yên cầu mọi giao thức ứng dụng được chỉnhsửa để hiểu tiến trình thương lượng. Ngoài ra, việc xác lập một tùy chọn TCP ( nghĩa là năng lực thứ ba ) là một giải pháp tốt, nhưng đó không được thảo luậnnghiêm túc cho đến giờ đây. Thực tế, những số cổng riêng không liên quan gì đến nhau đã được dành riêngvà được gán bởi IANA cho mọi giao thức ứng dụng vốn hoàn toàn có thể chạy trên SSLhoặc TLS ( nghĩa là năng lực thứ nhất ). Tuy nhiên, hãy chú ý quan tâm việc sử dụng cácsố cổng riêng không liên quan gì đến nhau cũng có khuyết điểm là yên cầu hai nối kết TCP nếu clientTrang 7 Đồ án môn học 3 Trang 8 không biết những gì mà server tương hỗ. Trước tiên, client phải nối kết với cổng antoàn và sau đó với cổng không bảo đảm an toàn hay ngược lại. Rất hoàn toàn có thể những giao thức saunày sẽ hủy bỏ giải pháp này và tìm năng lực thứ hai. Ví dụ, SALS ( SimpleAuthentication và Security Layer ) xác lập một tương thích để thêm sự tương hỗ xácthực vào những giao thức ứng dụng dựa vào liên kết. Theo thông số kỹ thuật kỹ thuật SALS, việc sử dụng những chính sách xác nhận hoàn toàn có thể thương lượng giữa client và server củamột giao thức ứng dụng đã cho. – Các số cổng được gán bởi IANA cho những giao thức ứng dụng vốn chạy trênSSL / TLS được tóm tắt trong bảng 1.1 và được minh họa một phần trong hình 2. Ngày nay, ” S ” chỉ định việc sử dụng SSL được thêm ( hậu tố ) đồng điệu vào cáctừ ghép của những giao thức ứng dụng tương ứng ( trong 1 số ít thuật ngữ bắt đầu, Sđược sử dụng và được thêm tiền tố một cách không đồng điệu và một số ít từ ghép ) Bảng1. 1 : Các số cổng được gán cho những giao thức ứng dụng chạy trên TLS / SSL. – Nói chung, một session SSL có trạng thái và giao thức SSL phải khởi tạo và duytrì thông tin trạng thái ở một trong hai phía của session. Các thành phần thông tintrạng thái session tương ứng gồm có một session ID, một ghi nhận nganghàng, một chiêu thức nén, một thông số kỹ thuật mật mã, một khóa mật chính và một cờvốn chỉ định việc session hoàn toàn có thể liên tục lại hay không, được tóm tắt trong bảng1. 2. Một session SSL hoàn toàn có thể được sử dụng trong một số ít liên kết và những thành phầnthông tin trạng thái nối kết tương ứng được tóm tắt trong bảng 1.3. Chúng baogồm những tham số mật mã, ví dụ điển hình như những chuỗi byte ngẫu nhiên server vàclient, những khóa mật MAC ghi server và client, những khóa ghi server và client, mộtvector khởi tạo và 1 số ít chuỗi. Ở trong hai trường hợp, điều quan trọng cần lưuý là những phía tiếp xúc phải sử dụng nhiều session SSL đồng thời và những sessioncó nhiều nối kết đồng thời. Trang 8 Đồ án môn học 3 Trang 9B ảng 1.2 Các thành phần thông tin trạng thái Session SSLBảng 1.3 Các thành phần thông tin trạng thái nối kết SSL1. 1.3. Phiên SSL và liên kết SSL – Các khái niệm đề cập ở trên là những khái niệm cơ bản của công nghệ tiên tiến SSL. Ngoài racòn có rất nhiều thuộc tính khác của SSL mà tất cả chúng ta sẽ xem xét ở đây : Trang 9 Đồ án môn học 3 Trang 10 • connection ( liên kết ) : là một link client / server logic với những kiểu dịch vụthích hợp. SSL connection là một liên kết điểm nối điểm giữa 2 nút mạng. • session ( phiên ) : là một sự phối hợp giữa một client và một server xác lập bằngmột bộ những tham số ví dụ thuật toán sẽ sử dụng, số hiệu phiên v.v Khi mộtphiên SSL giữa một client và một server được thiết lập bằng giao thức SSLHandshake Protocol thì tổng thể những liên kết sau này được thiết lập giữa cặpserver / client đó sẽ sử dụng chung bộ tham số đó mà không phải thực thi 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 servercó thể có nhiều liên kết giữa client và server đó. Về triết lý cũng hoàn toàn có thể có nhiềuphiên SSL dùng chung một liên kết, nhưng trên trong thực tiễn không sử dụng đến khảnăng này. Khái niệm phiên và liên kết SSL tương quan đến nhiều tham số sử dụngtrong truyền thông online tương hỗ SSL giữa client và server. Trong quy trình thoả thuậncủa giao thức handshake ngoài việc chọn những giải pháp mã hoá tài liệu thì mộtloạt những tham số của Session State cũng được chọn, Session State gồm có : Session identifier : là định danh do server tạo ra và gán cho mỗiphiên thao tác với một client nhất định, Peer certificate : chứng từ X. 509 của nút còn lại của phiên, Phương pháp nén : xác lập chiêu thức nén tài liệu trước khi mãhoá, Mô tả thuật toán CipherSpec : xác lập thuật toán để mã hoá dữliệu ( ví dụ thuật toán DES ) và thuật toán băm tài liệu ( ví dụ MD5 ) sẽ sử dụng trong phiên, Master secret : là 1 số ít bí hiểm 48 byte được server và client dùngchung, Cờ “ is resumable ” : cho biết hoàn toàn có thể sử dụng phiên này để khởi tạocác liên kết mới được không. Ngoài ra còn có một số ít tham số khác : Số ngẫu nhiên của Server và client : tài liệu ngẫu nhiên do cả clientvà server sinh ra cho mỗi liên kết, Server write MAC secret : chìa khoá bí hiểm do server sử dụng để mãhoá tài liệu của server, Trang 10 Đồ án môn học 3 Trang 11 Client write MAC secret : chìa khoá bí hiểm do client sử dụng để mãhoá tài liệu của client. Server write key : chìa khoá mà server dùng để mã hoá và clientdùng để giải thuật tài liệu. Client write key : chìa khoá mà client dùng để mã hoá và serverdùng để giải thuật tài liệu. Sequence number ( số thứ tự ) : server và client quản trị một cáchriêng rẽ những số thứ tự để đánh số những thông điệp gửi và nhận chomỗi liên kết. 1.4. SSL Record Protocol – SSL Record Protocol sử dụng để trao đổi toàn bộ những kiểu tài liệu trong một phiên – gồm có những thông điệp, tài liệu của những giao thức SSL khác và tài liệu của ứngdụng. – SSL Record Protocol tương quan đến việc bảo mật thông tin và bảo vệ toàn vẹn tài liệu. Mục đích của SSR Record Protocol là thu nhận những thông điệp mà ứng dụngchuẩn bị gửi, phân mảnh tài liệu cần truyền, đóng gói, bổ xung header tạo thànhmột đối tượng người dùng gọi là bản ghi ( record ), bản ghi đó được mã hoá và hoàn toàn có thể truyềnbằng giao thức TCP. – Bước tiên phong của quy trình sẵn sàng chuẩn bị truyền tài liệu là phân mảnh tài liệu, tức làchia nhỏ dòng tài liệu thành những mảnh kích cỡ 16KB ( hoặc nhỏ hơn ). Nhữngmảnh dữ liệu này sau đó hoàn toàn có thể được nén trước khi truyền. Sau đó khởi đầu quátrình tạo những bản ghi cho mỗi đơn vị chức năng tài liệu bằng cách bổ xung thêm header, mộtsố byte cho đủ kích cỡ qui định của bản ghi nếu kích cỡ bản ghi chưa đủ vàcuối cùng là phần MAC. MAC ( Message Authentication Code ) là mã xác thựcthông điệp sử dụng để khi phát tài liệu trong những phiên SSL. – Phần header của mỗi bản ghi chứa 2 thông tin quan trọng đó là độ dài của bản ghivà độ dài của khối tài liệu thêm vào phần tài liệu gốc. Phần dữ liệu của một bảnghi gồm : • tài liệu gốc, những byte bổ xung cho đủ kích cỡ gói tin qui định, giá trị MAC – MAC được sử dụng để kiểm chứng sự toàn vẹn của thông điệp chứa trong bảnghi gửi cùng với MAC đó. MAC là hiệu quả của một của một hàm băm theo mộtthuật toán băm được qui địng trước ( ví dụ MD5 hoặc SHA-1 ). – MAC được đo lường và thống kê dựa trên việc vận dụng hàm băm trên những tài liệu sau : khoá bímật, tài liệu gốc, phần thông tin bổ xung, số thứ tự. – Khoá bí hiểm ở đây hoàn toàn 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ớigiá 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ị đổi khác trong quy trình truyền trên mạng. Độ dài của trườngMAC phụ thuộc vào vào chiêu thức để tính ra nó. – Tiếp theo, phần dữ liệu cộng với MAC sẽ được mã hoá sử dụng chiêu thức 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êmheader gồm có những trường sau : Kiểu nội dung ( content type ) : xác lập tài 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 nghĩa vụ và trách nhiệm giải quyết và xử lý tài liệu của góitin đó. Các giá trị hoàn toàn có thể của trường này là : change_cipher_spec, alert, handshakevà application_data tham chiếu đến những 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 giám sát xong những trường này, bản ghi đã được tạo xong và chuẩn bị sẵn sàng đểgửi đến cho máy đích. Toàn bộ quy trình chuẩn bị sẵn sàng 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 ProtocolTrang 12 Đồ án môn học 3 Trang 131.1.5. Alert Protocol – Alert Protocol được những bên sử dụng để mang những thông điệp của phiên liên quantới việc trao đổi tài liệu và hoạt động giải trí của những giao thức. Mỗi thông điệp của giaothức này gồm 2 byte. Byte thứ nhất chứa một trong hai giá trị là warning ( 1 ) vàfatal ( 2 ) xác lập tính nghiêm trọng của thông điệp. Khi một trong 2 bên gửithông điệp có giá trị bít tiên phong là fatal ( 2 ) thì phiên thao tác giữa 2 bên sẽ kếtthúc ngay lập tức. Byte tiếp theo của thông điệp chứa mã lỗi xảy ra trong phiêngiao dịch SSL. 1.1.6. Change CipherSpec Protocol – Đây là giao thức SSL đơn thuần nhất. Nó chỉ chứa một thông điệp mang giá trị 1. Mục đích duy nhất của thông điệp này là làm chuyển trạng thái của một phiên từ “ đang chờ ” ( pending ) sang “ vững chắc ” ( fixed ). Ví dụ khi 2 bên qui ước bộ giaothức nào sẽ sử dụng. Cả client và server đều phải gửi thông điệp loại này cho bênđối tác, sau khi đã trao đổi xong thì coi như hai bên đã chấp thuận đồng ý với nhau. 1.1.7. Handshake Protocol – SSL Handshake Protocol là giao thức con SSL chính được xếp lớp trên SSLRecord Protocol. Kết quả, những thông tin thiết lập quan hệ SSL được cung ứng cholớp bản ghi SSL nơi chúng được phủ bọc trong một hoặc nhiều bản ghi SSL vốnđược giải quyết và xử lý và được chuyển như được xác lập bởi chiêu thức nén và thông sốmật mã của session SSL hiện hành và những khóa mật mã của nối kết SSL tươngứng. Mục đích của SSL Handshake Protocol là nhu yếu một client và server thiếtlập và duy trì thông tin trạng thái vốn được sử dụng để bảo vệ những cuộc liên lạc. Cụ thể hơn, giao thức phải nhu yếu client và server đồng ý chấp thuận một phiên bản giaothức SSL chung, chọn phương pháp nén và thông số kỹ thuật mật mã, tùy ý xác nhận nhauvà tạo một khóa mật chính mà từ đó những khóa session khác nhau dành cho việcxác thực và mã hóa thông tin hoàn toàn 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 Scó thể được tóm tắt như sau ( những thông tin được đặt trong những dấu ngoặc vuôngthì tùy ý ) : 1 : C -> S : CLIENTHELLO2 : S -> C : SERVERHELLO [ CERTIFICATE ] [ SERVERKEYEXCHANGE ] [ CERTIFICATEREQUEST ] SERVERHELLODONE3 : C -> [ CERTIFICATE ] CLIENTKEYEXCHANGE [ CERTIFICATEVERIFY ] Trang 13 Đồ án môn học 3 Trang 14CHANGECIPHERSPECFINISHED4 : S -> C : CHANGECIPHERSPECFINISHED – Khi Client C muốn liên kết với server S, nó thiết lập một nối kết TCP với cổngHTTPS ( vốn không được đưa vào phần diễn đạt giao thức ) và gởi một thông báoCLIENTHELLO đến server ở bước 1 của sự thực thi SSL HandshakeProtocol. Client cũng hoàn toàn có thể gởi một thông tin CLIENTHELLO nhằm mục đích phản hồilại một thông tin HELLOREQUEST hoặc dữ thế chủ động thương lượng lại những thamsố bảo mật thông tin của một nối kết hiện có. Thông báo CLIENTHELLO gồm có cáctrườ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 bộc lộ 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 hạn 32 bit có dạngUNIX 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 list những bộ mật mã client tương hỗ. Một list những giải pháp nén mà client tương hỗ. – Chú ý rằng trường session identity ( định danh session ) nên rỗng nếu session SSLhiện không sống sót hoặc nếu client muốn tạo những tham số bảo mật thông tin mới. Ở mộttrong hai trường hợp, một trường session identity không rỗng là xác lập mộtsession SSL hiện có giữa client và server ( nghĩa là một session có những tham sốbảo mật mà client muốn sử dụng lại. ). Định danh session hoàn toàn có thể bắt nguồn từ mộtnối kết trước đó, nối kết này hoặc một nối kết đang hoạt động giải trí. Cũng chú ý quan tâm rằngdanh sách những bộ mật mã được tương hỗ, được chuyển từ client đến servertrong thông tin CLIENTHELLO, chứa những tổng hợp thuật toán mật mã được hỗtrợ bởi client theo thứ tự ưu tiêm. Mỗi bộ mật mã xác lập một thuật toán trao đổikhóa và một thông tin mật mã. Server sẽ chọn một bộ mật mã hoặc nếu những lựachọn hoàn toàn có thể gật đầu được không được trình bầy, trả về một thông tin lỗi vàđóng nối kết một cách tương thích. Sau khi đã gởi thông tin CLIENTHELLO, client đợi một thông tin SERVERHELLO. Bất kỳ thông tin khác được trả vềbởi server ngoại trừ một thông tin HELLOREQUEST được xem như thể một lỗivào thời gian này. – Ở bước 2, server giải quyết và xử lý thông tin CLIENTHELLO và phân phối bằng một thôngbáo lỗi hoặc thông tin SERVERHELLO.Tương tự như thông báoCLIENTHELLO, thông tin SERVERHELLO có những 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 tin CLIENTHELLO và được tương hỗ cao nhất bởiServer. – Một cấu trúc ngẫu nhiên do server tạo ra cũng gồm một tem thời hạn 32 bit códạng UNIX chuẩn và một giá trị 28 bit được tạo ra bởi một bộ tạo số ngẫu nhiên. – Một định danh session tương ứng với nối kết này. – Một bộ mật mã được chọn từ bởi server từ list những bộ mật mã được hỗ trợbởi client. – Một chiêu thức nén được chọn bởi server từ list những thuật toán nén đượchỗ trợ bởi client. – Nếu định danh session trong thông tin CLIENTHELLO không rỗng, server tìmtrong cache session của nó nhằm mục đích tìm ra một mục tương hợp. Nếu mục tương hợpđược tìm thấy và server muốn thiết lập nối kết mới bằng cách sử dụng trạng tháisession tương ứng, server cung ứng bằng cùng một giá trị như được cung ứng bởiTrang 15 Đồ án môn học 3 Trang 16 client. Chỉ địn này là một session được liên tục lại và xác lập rằng cả hai phíaphải triển khai trực tiếp với những thông tin CHANGECIPHERSPEC vàFINISHED được trình diễn 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 hoàn toàn có thể trả về một trường địnhdanh session rỗng để bộc lộ rằng session sẽ không được tàng trữ và do đó khôngthể được liên tục sau đó. Cũng quan tâm rằng trong thông báoSERVERHELLO, server chọn một bộ mật mã và một giải pháp nén từcác list được cung ứng bởi client trong thông tin CLIENTHELLO.Các thuật toán trao đổi khóa, xác nhận, mã hóa và xác nhận thông tin được xácđịnh bởi bộ mã được chọn bởi server và được làm lộ ra trong thông báoSERVERHELLO. Các bộ mật mã vốn đã được xác lập trong giao thức SSL vềcơ bản giống như bộ mật mã đã xác lập cho TLS ( như được tóm tắt ở những bản1. 4 đến 1.7 trong những bài viết trước ). – Ngoài thông tin SERVERHELLO, server cũng phải gởi những thông tin khác đếnclient. Ví dụ, nếu server sử dụng sự xác thức dựa vào chứng nhân, server gởichứng nhận site của nó đến client trong một thông tin 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ã đượcchọn và thường là một ghi nhận X. 509 v3. Cùng loại thông tin sẽ được sửdụng sau đó cho sự phân phối của client so với thông tin sẽ được sử dụng sau đócho sự phân phối của client so với thông tin CERTIFICATERequest của server. Trong trường hợp của những ghi nhận X. 509 v3, một ghi nhận hoàn toàn có thể thực sựtham chiếu đến hàng loạt một chuỗi những ghi nhận, được sắp xếp theo thứ tự vớichứng nhận của đối tượng người dùng gởi thứ nhất theo sau là bất kể ghi nhận CA tiếnhành theo trình tự hướng đến một CA gốc ( vốn sẽ được gật đầu bởi client ). – Tiếp theo, server hoàn toàn có thể gởi một thông tin SERVERKEYEXCHANGE đếnclient nếu nó không có ghi nhận, một ghi nhận vốn hoàn toàn có thể được sử dụngchỉ để xác nhận những chữ ký kỹ thuật số hoặc sử dụng thuật toán trao đổi khóa dựavào token FORITEZZA ( KEA ). Rõ ràng, thông tin này không được nhu yếu nếuchứng nhận site gồm một khóa chung RSA vốn hoàn toàn có thể được sử dụng trong việcmã hóa. Ngoài ra, một server không nặc danh hoàn toàn có thể tùy ý nhu yếu một chứngnhận cá thể để xác nhận client. Do đó, nó gởi một thông báoCERTIFICATERequest đến client. Thông báo này chứa một list những loạichứng nhận được nhu yếu, được phân loại theo thứ tự ưu tiên của server cũng nhưmột list những tên được phân biệt cho những CA hoàn toàn có thể gật đầu. Ởcuối bước 2, server gởi một thông tin SERVERHELLODone đến client để chỉđịnh sự kết thúc SERVERHELLO và những thông tin đi kèm. – Sau khi nhận SERVERHELLO và những thông tin đi kèm, client xác nhận rằngchứng nhận site server ( nếu được cung ứng ) là hợp lệ và kiểm tra nhằm mục đích bảo đảmrằng những thông số kỹ thuật bảo mật thông tin được phân phối trong thông tin SERVERHELLO cóthể được gật đầu. Nếu server nhu yếu sự xác nhận client, client gởi một thôngbáo CERTIFICATE vốn chứa một ghi nhận cá thể cho khóa chung củangười dùng đến server ở bước 3. Tiếp theo, client gởi một thông báoTrang 16 Đồ án môn học 3 Trang 17CLIENTKEYEXCHANGE có dạng nhờ vào vào thuật toán cho mỗi khóa đượcchọn bởi server : – Nếu RSA được sử dụng cho việc xác nhận server và trao đổi khóa, client tạo mộtkhóa mật tiền chính 48 byte, mã hóa nó bằng khóa chung được tìm thấy trongchứng nhận site hoặc khóa RSA trong thời điểm tạm thời từ thông báoSERVERKEYEXCHANGE và gởi hiệu quả quay trở lại server trong thông báoCLIENTKEYEXCHANGE. 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 những token FORTEZZA được sử dụng để trao đổi khóa, client dẫn xuất mộtkhó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ừ ghi nhận server cùng với 1 số ít tham số riêng trongtoken của client. Client gởi những tham số chung thiết yếu cho server để cũng tạoTEK, sử dụng những tham sô riêng của nó. Nó tạo một khóa mật chính, bảo phủ nóbằng cách sử dụng TEK và gởi hiệu quả cùng với 1 số ít vector khởi tạo đếnserver như thể một phần của thông tin CLIENTKEYEXCHANGE. Lần lượt, server hoàn toàn có thể giải thuật khóa mật chính một cách thích hợp. Thuật toán trao đổikhóa này không được sử dụng thoáng đãng. – Nếu sự xác nhận client được nhu yếu, client cũng gởi một thông báoCERTIFICATEVERIFY đến server. Thông báo này được sử dụng để cung cấpsự xác nhận rõ ràng định danh của người dùng dựa vào ghi nhận những nhân. Nó chỉ được gởi theo sau một chứng từ client vốn có năng lực tạo chữ ký ( tất cảchứng nhận ngoại trừ những ghi nhận chứa những 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áoCHANGECIPHERSPEC và một thông tin 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áoCHANGECIPERSPEC để xác nhận rằng những tiến trình trao đổi khóa và xác thựcđã thành công xuất sắc. Thực tế, thông tin FINISHED là thông tin tiên phong vốn được bảovệ bằng những thuật toán mới được thương lượng và những 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 setup một cách tương thích ởcả hai phía. Không yên cầu sự báo nhận thông tin FINISHED ; những phía hoàn toàn có thể bắtđầu gởi tài liệu được mã hóa ngay lập tức sau khi đã gởi thông tin FINISHED.Việc thực thi SSL Handshake Protocol hoàn tất bằng việc cũng nhu yếu server gởimột thông tin CHANGECIPHERSPEC và một thông tin 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 bảo đảm an toàn được thiết lập giữa client vàserver. Nối kết này giờ đây hoàn toàn có thể được sử dụng để gởi tài liệu ứng dụng vốnđược bảo phủ bởi SSL Record Protocol. Chính xác hơn, tài 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 nhận theo SSL RecordProtocol cũng như thông tin trạng thái session và nối kết vốn giờ đây được thiếtlập ( tùy thuộc việc thực thi SSL Handshake Protocol ). – SSL Handshake Protocol hoàn toàn có thể được rutst ngắn nếu client và server quyết địnhtiếp tục lại một session SSL được thiết lập trước đó ( và vẫn được tàng trữ ) hoặclặp lại một session SSL hiện có. Trong trường hợp này, chỉ ba dòng thông báoTrang 17 Đồ án môn học 3 Trang 18 và tổng số sáu thông tin được nhu yếu. Các dòng thông tin tương ứng có thểđược tóm tắt như sau : 1 : C -> S : CLIENTHELLO2 : S -> C : SERVERHELLOCHANECIPHERSPECFINISHED3 : S -> C : CHANGECIPHERSPECFINISHED – Ở bước 1, client gởi một thông tin CLIENTHELLO đến server vốn có một địnhdanh session cần được liên tục lại. Lần lượt server kiểm tra cache session của nóđể tìm một mục tương hợp. Nếu một mục tương hợp được tìm thấy, server muốntiếp tục lại nối kết bên dưới trạng thái session đã xác lập, nó trả về một thôngbáo SERVERHELLO với cùng một định danh session ở bước 2. Vào thờiđiểm này, cả client lẫn server phải gởi những thông báoCHANGECIPHERSPEC và FINISHED đến nhau ở bước 2 và 3. Một khi việctái thiết lập session hoàn tất, client và server hoàn toàn có thể mở màn trao đổi tài liệu ứngdụng. 1.1.8. Phân tích bảo mật thông tin – Sự nghiên cứu và phân tích bảo mật thông tin tổng lực về SSL 3.0 đã được triển khai bởi BruceScheneier và David Wagner vào năm 1996. Ngoại trừ một số ít khiếm khuyết nhỏvà những tính năng gây lo ngại vốn hoàn toàn có thể được sữa chữa thuận tiện mà không cầntu sửa cấu trúc cơ bản của giao thức SSL, họ không tìm thấy yếu tố điểm yếuhoặc bảo mật thông tin nghiêm trọng trong việc nghiên cứu và phân tích của họ. Kết quả, họ kết luậnrằng giao thức SSL phân phối sự bảo mật thông tin tuyệt vời ngăn việc nghe lén và nhữngcuộc tiến công thụ động khác, và người thực thi giao thức này sẽ ý thức đếnmột số cuộc tiến công dữ thế chủ động phức tạp. – Tuy nhiên, một vài tháng sau, Daniel Bleichenbacher từ Bell Laboratoires đã tìmthấy một cuộc tiến công text mật mã được chọn thích ứng nhắm những giao thức dựavào tiêu chuẩn mà khóa chung ( PKCS ) # 1. Cuộc tiến công đã được xuất bản vàonăm 1998. Tóm lại, một hoạt động giải trí khóa riêng RSA ( một hoạt động giải trí giải thuật hoặcchữ ký kỹ thuật số hoàn toàn có thể được triển khai nếu kẻ tiến công truy vấn 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ố ít khối tài liệu không được biết được mã hóa bằng cách sửdụng PKCS # 1 hay không. ) – Để khám phá cuộc tiến công Bleichenbacher, cần phải xem PKCS # 1. Thực tế, cóba dạng khối được xác lập trong PKCS # 1 : những loại khối 0 và 1 được sử dụngcho những chữ ký kỹ thuật số RSA và loại khối 2 được sử dụng cho việc mã hóaRSA. Các phần tranh luận trước, hãy nhớ rằng nếu thuật toán RSA được sử dụngcho việc xác nhận server và trao đổi khóa, client tạo ngẫu nhiên một khóa mậtchính 46 byte, thêm tiền tố hai byte 03 ( số phiên bản giao thức SSL ) và 00 vàokhóa mật chính, mã hóa hiệu 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 tin CLIENTKEYEXCHANGE đến server. Do đó, thôngbáo CLIENTkEYEXCHANGE mang khóa mật chính được mã hóa phải phù hợpvới dạng được xác lập trong loại khóa 2 PKCS # 1. – Bây giờ giả sử có một kẻ tiến công hoàn toàn có thể gửi một số ít tùy ý của những thông tin ngẫunhiên đến một server SSL và server phân phối cho từng thông tin này bằng 1 bitchỉ định xem một thông tin đơn cử có được mã hóa đúng mực và được mã hóatheo PKCL # 1 ( do đó server có công dụng như một oracle hay không ). Với sự giảđịnh này, Bleichenbacher đã tăng trưởng một cuộc tiến công để triển khai một hoạtđộng RSA một cách phạm pháp với khóa riêng của server ( với một hoạt độnggiải hoặc một chữ ký kỹ thuật số ). Khi được vận dụng để giải thuật một khóa mậtchính của thông tin CLIENTKEYEXCHANGE được gửi trước đó, kẻ tấn côngcó 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áchphù hợp. Kết quả, sau đó kẻ tiến công hoàn toàn có thể giải thuật hàng loạt session ( nếu ngườinày đã giám sát và tàng trữ dòng tài liệu của session đó ). – Nếu cuộc tiến công có sức chú ý quan tâm về mặt kim chỉ nan. Chú ý rằng hiệu quả thử nghiệmđã cho thấy thường giữa 300.000 và 2 triệu text mật mã được chọn được yêu cầuđể thực sự triển khai hoạt động giải trí ( giải thuật hoặc chữ ký kỹ thuật số ). Để làm chomọi thứ trở nên tệ hơn, cuộc tiến công hoàn toàn có thể được thực thi trên một server SSLvốn có sẵn on-line ( vì nó phải hoạt động giải trí như một oracle ). Từ quan điểm của kẻtấn công, hoàn toàn có thể khó gửi số lượng lớn text mật mã được chọn này đến server SSLmà không làm cho nhà quản trị server trở lên hoài nghi. – Có 1 số ít năng lực để ngăn ngừa sự tiến công Bleichenbacher. Trên hết, serverkhông cần phân phối lại một thông tin lỗi sau khi đã nhận một thông báoCLIENTKEYEXCHANGE vốn không tương thích với PKCS # 1. Một năng lực kháclà đổi khác dạng khối PKCS # 1 để mã hóa và vô hiệu những byte 00 và 02 dẫn đầucũng như những byte 00, 03 và 00 ở giữa thông tin ( như được minh họa trong hình6. 3 ). Sau cùng, một năng lực khác là sử dụng những sơ đồ mã hóa có năng lực nhậnbiết text thuần túy ví dụ điển hình như những sơ đồ được đề xuất kiến nghị bởi Mihir Bellar vàPhilip Rogaway và bất kể mạng lưới hệ thống mật mã khóa chng khác vốn hoàn toàn có thể bảo vệngăn ngừa những cuộc tiến công text mật mã được chọn thích ứng. Trang 19 Đồ án môn học 3 Trang 201.2. HTTPS1. 2.1. Giao thức HTTP và HTTPSHTTP là gì ? – HTTP là chữ viết tắt từ HyperText Transfer Protocol ( giao thức truyền tải siêuvăn bản ). Nó là giao thức cơ bản mà World Wide Web sử dụng. HTTP xác địnhcách những thông điệp ( những file văn bản, hình ảnh đồ hoạ, âm thanh, video, và cácfile multimedia khác ) được định dạng và truyền tải thế nào, và những hành độngnào mà những Web server ( sever Web ) và những trình duyệt Web ( browser ) phảilàm để phân phối những lệnh rất phong phú. Chẳng hạn, khi bạn gõ một địa chỉ WebURL vào trình duyệt Web, một lệnh HTTP sẽ được gửi tới Web server để ra lệnhvà hướng dẫn nó tìm đúng trang Web được nhu yếu và kéo về mở trên trình duyệtWeb. Nói nôm na hơn, HTTP là giao thức truyền tải những file từ một Web servervào một trình duyệt Web để người dùng hoàn toàn có thể xem một trang Web đang hiệndiện trên Internet. HTTP là một giao thức ứng dụng của bộ giao thức TCP / IP ( cácgiao thức nền tảng cho Internet ). HTTPS là gì ? – HTTPS ( Secure HTTP ), là một sự tích hợp giữa giao thức HTTP và giao thức bảomật SSL hay TLS được cho phép trao đổi thông tin một cách bảo mật thông tin trên Internet. Cáckết nối HTTPS thường được sử dụng cho những thanh toán giao dịch giao dịch thanh toán trên WorldWide Web và cho những thanh toán giao dịch nhạy cảm trong những mạng lưới hệ thống thông tin công ty. HTTPS được sử dụng trong nhiều trường hợp, ví dụ điển hình như những trang đăng nhậpcho ngân hàng nhà nước, những hình thức, ích đăng nhập công ty, và những ứng dụng khác, trongđó tài liệu cần phải được bảo đảm an toàn. HTTPS không nên nhầm lẫn với Secure HTTP ( S-HTTP ) lao lý trong RFC 2660.1.2.2. Phân tích hoạt động giải trí của giao thức HTTPS – Giao thức HTTPS sử dụng port 443, và phân phối những dịch vụ hay bảo vệ tínhchất sau của thông tin : Confidentiality : sử dụng phương pháp encryption để bảo vệ rằng những 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 pháp hashing để cả client và server đều hoàn toàn có thể tintưở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 hoàn toàn có thể tin yêu rằngserver / website mà họ đang truy vấn thực sự là server / website mà họ mong muốnvào, chứ không phải bị trá hình. Trang 20 Đồ án môn học 3 Trang 211.2.2.1. Sử dụng HTTPS như thế nào ? – Trước hết, muốn vận dụng HTTPS thì trong quy trình thông số kỹ thuật 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ó đượcgọ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 online giữa server và client. Nhưng rõ ràng là không đạt đượctính Authenticity chính do không có bên thứ 3 đáng đáng tin cậy nào ( hay CA ) đứng rakiểm chứng sự tính xác nhận của certificate tự gán này. Điều này cũng giống nhưviệc một người tự làm chứng minh nhân dân ( CMND ) cho mình rồi tự họ ký tên, đóng dấu luôn vậy ! Vì vậy, so với những website quan trọng như E-Commerce, Online Payment, WebMail, … thì họ sẽ mua một SSL certificate từ một Trusted Root CA nổi tiếng nhưVeriSign, Thawte, và ít tên tuổi hơn thì có GoDaddy, DynDNS … Các CA có 2 trách nhiệm chính sau : – Cấp phát và quản trị SSL certificate cho server / website. – Xác thực sự sống sót và tính hiệu lực hiện hành của SSL certificate mà Web client gửi tớicho nó. Thực chất thì SSL certificate cũng là một loại digitial certificate ( một loại file trênmáy tính ). Vì giao thức HTTPS có dính tới giao thức SSL nên người ta mới đặttên cho nó là SSL certificate để phân biệt với những loại digital certificate khácnhư Personal Certificate, Server Certificate, Software Publisher Certificate, Certificate Authority Certificate. Dưới đây là 1 số ít thông tin quan trọng được chứa trong SSL certificate mà bấtcứ client nào cũng hoàn toàn có thể xem được bằng cách click vào hình tượng padlock trênthanh Address của Web browser : – tin tức về owner của certificate ( như tên tổ chức triển khai, tên cá thể hoặc domaincủa website … ). – Tên và digital signature của CA cấp certificate. – Khoảng thời hạn mà certificate còn hiệu lực hiện hành sử dụng. – Public key của server / website. Còn private key được tàng trữ trên chính server ( không có trong certificate ) và tuyệt đối không hề để lộ cho bất kỳ client nào. – Một số thông tin phụ khác như : loại SSL certificate, những thuật toán dùng đểencryption và hashing, chiều dài ( tính bằng bit ) của key, chính sách trao đổi key ( nhưTrang 21 Đồ án môn học 3 Trang 22RSA, DSA … ). 1.2.2. 2. Quá trình tiếp xúc giữa client và server trải qua HTTPS1. Client gửi request cho một secure page ( có URL mở màn 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ểmchứng. Giả sử certificate đã được xác nhận và còn hạn sử dụng hoặc client vẫn cố tìnhtruy cập mặc dầu Web browser đã cảnh báo nhắc nhở rằng không hề đáng tin cậy đượccertificate này ( do là dạng self-signed SSL certificate hoặc certificate hết hiệulự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 publickey ( 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 thuật 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 tiếp thị quảng cáo. Và tất yếu, những symmetric key sẽ được tạo ra ngẫu nhiên và hoàn toàn có thể khácnhau trong mỗi phiên thao tác với server. Ngoài encryption thì chính sách hashingsẽ được sử dụng để bảo vệ tính Integrity cho những thông điệp được trao đổi. 1.2.3 SMTPSTrang 22 Đồ án môn học 3 Trang 231.2.3.1 Giao thức SMTP và SMTPSSMTP là gì ? – SMTP ( tiếng Anh : Simple Mail Transfer Protocol – giao thức truyền tảithư tín đơn thuầ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 lan rộng ra ), đượ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 thuần. Trướckhi một thông điệp được gửi, người ta hoàn toàn có thể xác định một hoặc nhiều địachỉ nhận cho thông điệp – những địa chỉ này thường được kiểm tra về sựtồn tại trung thực của chúng ). Việc kiểm thử một trình chủ SMTP là mộtviệc tương đối thuận tiện, dùng chương trình ứng dụng ” telnet. o SMTP dùng cổng 25 của giao thức TCP. Để xác lập trình chủ SMTP củamột tên miền nào đấy ( domain name ), người ta dùng một mẫu tin MX ( Mail eXchange – Trao đổi thư ) của DNS ( Domain Name System – Hệthống tên miền ). o SMTP khởi đầu được sử dụng thoáng đãng vào những năm đầu thập niên kỷ1980. Tại thời gian đó, SMTP chỉ là một ứng dụng bổ trợ của bộ trìnhứng dụng đồng giao thức UUCP ( Unix to Unix CoPy – Sao chép từ máyUnix sang máy Unix ) nhưng tiện nghi hơn trong việc truyền tải thư điện tửgiữa những máy vi tính – những máy này nhiều lúc mới lại được kết nốivới nhau một lần, để tiếp thị quảng cáo tài liệu. Thực ra, SMTP sẽ thao tác tốthơn nếu những máy gửi và máy nhận được liên kết liên tục. Sendmail là mộttrong những ứng dụng đặc vụ truyền tải thư tín ( mail transfer agent ) đầutiên ( nếu không phải là cái thứ nhất nhất ) thực thi giao thức SMTP. Tínhđến năm 2001, người ta đã thấy có tối thiểu là 50 chương trình ứng dụngthực thi giao thức SMTP, gồm có cả trình khách ( ứng dụng dùng để gửithông điệp ) và trình chủ ( ứng dụng dùng để nhận thông điệp ). Một sốtrình chủ SMTP nổi tiếng hoàn toàn có thể liệt kê gồm có : exim, Postfix, qmail, vàMicrosoft Exchange Server. o Do phong cách thiết kế của giao thức dùng dạng thức văn bản thường của bộ mãASCII, khi bản thiết kế được thi công, tính năng của SMTP giải quyếttập tin có dạng thức nhi phân rất kém. Những tiêu chuẩn như MIME đãđược kiến thiết xây dựng để mã hóa những tập tin nhị phân, được cho phép chúng đượctruyền tải dùng giao thức SMTP. Hiện nay, hầu hết những trình chủ SMTPhỗ trở phần lan rộng ra 8BITMIME của SMTP, được cho phép những tập tin ở dạngthức nhị phân được truyền thông online qua đường dây, dễ như việc truyền tảivăn bản thường vậy. Trang 23
Source: https://mindovermetal.org
Category: Ứng dụng hay