Nghiên cứu các giao thức để đảm bảo an ninh và đường truyền. lấy ví dụ minh họa

Bài tiểu luận môn: An toàn bảo mật thông tin
BÀI TIỂU LUẬN MÔN: AN TOÀN BẢO MẬT THÔNG TIN
ĐỀ BÀI: Nghiên cứu các giao thức để đảm bảo an ninh và
đường truyền. lấy ví dụ minh họa.
An toàn nghĩa là thông tin được bảo vệ, các hệ thống và những dịch vụ có
khả năng chống lại những tai hoạ, lỗi và sự tác động không mong đợi, các thay
đổi tác động đến độ an toàn của hệ thống là nhỏ nhất. Hệ thống có một trong các
đặc điểm sau là không an toàn: Các thông tin dữ liệu trong hệ thống bị người
không được quyền truy nhập tìm cách lấy và sử dụng (thông tin bị rò rỉ). Các
thông tin trong hệ thống bị thay thế hoặc sửa đổi làm sai lệch nội dung (thông tin
bị xáo trộn)
Thông tin chỉ có giá trị cao khi đảm bảo tính chính xác và kịp thời, hệ thống
chỉ có thể cung cấp các thông tin có giá trị thực sự khi các chức năng của
hệ thống đảm bảo hoạt động đúng đắn. Mục tiêu của an toàn bảo mật trong công
nghệ thông tin là đưa ra một số tiêu chuẩn an toàn. Ứng dụng các tiêu chuẩn an
toàn này vào đâu để loại trừ hoặc giảm bớt các nguy hiểm. Do kỹ thuật truyền
nhận và xử lý thông tin ngày càng phát triển đáp ứng cácyêu cầu ngày càng cao
nên hệ thống chỉ có thể đạt tới độ an toàn nào đó. Quản lý an toàn và sự rủi ro
được gắn chặt với quản lý chất lượng. Khi đánh giá độ an toàn thông tin cần phải
dựa trên phân tích các rủi ro, tăng sự an toàn bằng cách giảm tối thiểu rủi ro.
Các đánh giá cần hài hoà với đặc tính, cấu trúc hệ thống và quá trình kiểm tra
chất lượng.

AN TOÀN ĐƯỜNG TRUYỀN
Trong an toàn thông tin thì đảm bảo đường truyền là một trong những
vấn đề đáng quan tâm. Trong đó có 2 giao thức cơ bản là IPsec & SSL
I. IPSec
Lý do cần IPSec
• Có những vấn đề an toàn cần giải quyết ở mức thấp hơn tầng ứng dụng
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:1
Bài tiểu luận môn: An toàn bảo mật thông tin

• Đặc biệt các hình thức tấn công ở tầng IP rất phổ biến như giả mạo IP,
xem trộm gói tin
• An toàn ở mức IP sẽ đảm bảo an toàn cho tất cả các ứng dụng
• Bao gồm nhiều ứng dụng chưa có tính năng an toàn
Các cơ chế an toàn của IPSec
Xác thực
Bảo mật
Quản lý khóa
1.1 Tổng quan IPSec
Giao thức IPsec được làm việc tại tầng Network Layer – layer 3 của mô hình
OSI. Các giao thức bảo mật trên Internet khác như SSL, TLS và SSH, được thực
hiện từ tầng transport layer trở lên (Từ tầng 4 tới tầng 7 mô hình OSI). Điều này
tạo ra tính mềm dẻo cho IPsec, giao thức này có thể hoạt động từ tầng 4 với TCP,
UDP, hầu hết các giao thức sử dụng tại tầng này. IPsec có một tính năng cao cấp
hơn SSL và các phương thức khác hoạt động tại các tầng trên của mô hình OSI.
Với một ứng dụng sử dụng IPsec mã (code) không bị thay đổi, nhưng nếu ứng
dụng đó bắt buộc sử dụng SSL và các giao thức bảo mật trên các tầng trên trong
mô hình OSI thì đoạn mã ứng dụng đó sẽ bị thay đổi lớn.

1.2 Cấu trúc bảo mật
IPsec được triển khai (1) sử dụng các giao thức cung cấp mật
mã (cryptographic protocols) nhằm bảo mật gói tin (packet) trong quá trình
truyền, (2) phương thức xác thực và (3) thiết lập các thông số mã hoá.
Xây dựng IPsec sử dụng khái niệm về bảo mật trên nền tảng IP. Một sự kết
hợp bảo mật rất đơn giản khi kết hợp các thuật toán và các thông số (ví như các
khoá – keys) là nền tảng trong việc mã hoá và xác thực trong một chiều. Tuy
nhiên trong các giao tiếp hai chiều, các giao thức bảo mật sẽ làm việc với nhau
và đáp ứng quá trình giao tiếp. Thực tế lựa chọn các thuật toán mã hoá và xác
thực lại phụ thuộc vào người quản trị IPsec bởi IPsec bao gồm một nhóm các
giao thức bảo mật đáp ứng mã hoá và xác thực cho mỗi gói tin IP.

Trong các bước thực hiện phải quyết định cái gì cần bảo vệ và cung cấp cho
một gói tin outgoing (đi ra ngoài), IPsec sử dụng các thông số Security Parameter
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:2
Bài tiểu luận môn: An toàn bảo mật thông tin
Index (SPI), mỗi quá trình Index (đánh thứ tự và lưu trong dữ liệu – Index ví
như một cuốn danh bạ điện thoại) bao gồm Security Association Database
(SADB), theo suốt chiều dài của địa chỉ đích trong header của gói tin, cùng với
sự nhận dạng duy nhất của một thoả hiệp bảo mật (tạm dịch từ - security
association) cho mỗi gói tin. Một quá trình tương tự cũng được làm với gói tin đi
vào (incoming packet), nơi IPsec thực hiện quá trình giải mã và kiểm tra các
khoá từ SADB.
Cho các gói multicast, một thoả hiệp bảo mật sẽ cung cấp cho một group,
và thực hiện cho toàn bộ các receiver trong group đó. Có thể có hơn một
thoả hiệp bảo mật cho một group, bằng cách sử dụng các SPI khác nhau, tuy
nhiên nó cũng cho phép thực hiện nhiều mức độ bảo mật cho một group. Mỗi
người gửi có thể có nhiều thoả hiệp bảo mật, cho phép xác thực, trong khi người
nhận chỉ biết được các keys được gửi đi trong dữ liêu. Chú ý các chuẩn không
miêu tả làm thế nào để các thoả hiệp và lựa chọn việc nhân bản từ group tới các
cá nhân.
1.3 Hiện trạng
IPsec là một phần bắt bược của IPv6, có thể được lựa chọn khi sử dụng IPv4.
Trong khi các chuẩn đã được thiết kết cho các phiên bản IP giống nhau,
phổ biến hiện nay là áp dụng và triển khai trên nền tảng IPv4.
Các giao thức IPsec được định nghĩa từ RFCs 1825 – 1829, và được phổ biến
năm 1995. Năm 1998, được nâng cấp với các phiên bản RFC 2401 – 2412, nó
không tương thích với chuẩn 1825 – 1929. Trong tháng 12 năm 2005,
thế hệ thứ 3 của chuẩn IPSec, RFC 4301 – 4309. Cũng không khác nhiều so với
chuẩn RFC 2401 – 2412 nhưng thế hệ mới được cung cấp chuẩn IKE second.
Trong thế hệ mới này IP security cũng được viết tắt lại là IPsec.
Sự khác nhau trong quy định viết tắt trong thế hệ được quy chuẩn bởi RFC

1825 – 1829 là ESP còn phiên bản mới là ESPbis.
1.4 Thiết kế theo yêu cầu.
IPsec được cung cấp bởi Transport mode (end-to-end) đáp ứng bảo mật giữa
các máy tính giao tiếp trực tiếp với nhau hoặc sử dụng Tunnel mode (portal-to-
portal) cho các giao tiếp giữa hai mạng với nhau và chủ yếu được sử dụng khi kết
nối VPN.
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:3
Bài tiểu luận môn: An toàn bảo mật thông tin
IPsec có thể được sử dụng trong các giao tiếp VPN, sử dụng rất nhiều trong
giao tiếp. Tuy nhiên trong việc triển khai thực hiện sẽ có sự khác nhau giữa hai
mode này.
Giao tiếp end-to-end được bảo mật trong mạng Internet được phát triển chậm
và phải chờ đợi rất lâu. Một phần bở lý do tính phổ thông của no không cao, hay
không thiết thực, Public Key Infrastructure (PKI) được sử dụng trong phương
thức này.
IPsec đã được giới thiệu và cung cấp các dịch vụ bảo mật:
1. Mã hoá quá trình truyền thông tin
2. Đảm bảo tính nguyên ven của dữ liệu
3. Phải được xác thực giữa các giao tiếp
4. Chống quá trình replay trong các phiên bảo mật.
1.5 Modes – Các mode
Có hai mode khi thực hiện IPsec đó là: Transport mode và tunnel mode.
Transport mode
Trong Transport mode, chỉ những dữ liệu bạn giao tiếp các gói tin được
mã hoá và/hoặc xác thực. Trong quá trình routing, cả IP header đều không bị
chỉnh sửa hay mã hoá; tuy nhiên khi authentication header được sử dụng, địa
chỉ IP không thể biết được, bởi các thông tin đã bị hash (băm). Transport
và application layers thường được bảo mật bởi hàm băm (hash), và chúng không
thể chỉnh sửa (ví dụ như port number). Transport mode sử dụng trong tình huống
giao tiếp host-to-host.

Điều này có nghĩa là đóng gói các thông tin trong IPsec cho NAT traversal
được định nghĩa bởi các thông tin trong tài liệu của RFC bởi NAT-T.
Tunnel mode
Trong tunnel mode, toàn bộ gói IP (bao gồm cả data và header) sẽ được
mã hoá và xác thực. Nó phải được đóng gói lại trong một dạng IP packet khác
trong quá trình routing của router. Tunnel mode được sử dụng trong giao tiếp
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:4
Bài tiểu luận môn: An toàn bảo mật thông tin
network-to-network (hay giữa các routers với nhau), hoặc host-to-network và
host-to-host trên internet.
1.6 Technical details
Có hai giao thức được phát triển và cung cấp bảo mật cho các gói tin của cả hai
phiên bản IPv4 và IPv6:
IP Authentication Header giúp đảm bảo tính toàn vẹn và cung cấp xác thực.
IP Encapsulating Security Payload cung cấp bảo mật, và là option bạn
có thể lựa chọn cả tính năng authentication và Integrity đảm bảo tính toàn vẹn
dữ liệu.
Thuật toán mã hoá được sử dụng trong IPsec bao gồm HMAC-SHA1 cho tính
toàn vẹn dữ liệu (integrity protection), và thuật toán TripleDES-CBC và AES-
CBC cho mã mã hoá và đảm bảo độ an toàn của gói tin. Toàn bộ thuật toán
này được thể hiện trong RFC 4305.
a. Authentication Header (AH)
AH được sử dụng trong các kết nối không có tính đảm bảo dữ liệu. Hơn nữa
nó là lựa chọn nhằm chống lại các tấn công replay attack bằng cách sử dụng
công nghệ tấn công sliding windows và discarding older packets. AH bảo
vệ quá trình truyền dữ liệu khi sử dụng IP. Trong IPv4, IP header có bao gồm
TOS, Flags, Fragment Offset, TTL, và Header Checksum. AH thực hiện trực tiếp
trong phần đầu tiên của gói tin IP. dưới đây là mô hình của AH header.
5. Các modes thực hiện
0 - 7 bit 8 - 15 bit 16 - 23 bit24 - 31 bit

Next headerPayload lengthRESERVED
Security parameters index (SPI)
Sequence number
Authentication data (variable)
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:5
Bài tiểu luận môn: An toàn bảo mật thông tin
Ý nghĩa của từng phần:
Next header :Nhận dạng giao thức trong sử dụng truyền thông tin.
Payload length :Độ lớn của gói tin AH.
RESERVED :Sử dụng trong tương lai (cho tới thời điểm này nó được biểu diễn
bằng các số 0).
Security parameters index (SPI) : Nhận ra các thông số bảo mật, được tích hợp
với địa chỉ IP, và nhận dạng các thương lượng bảo mật được kết hợp với gói tin.
Sequence number :Một số tự động tăng lên mỗi gói tin, sử dụng nhằm chống lại
tấn công dạng
b. Encapsulating Security Payload (ESP)
Giao thức ESP cung cấp xác thực, độ toàn vẹn, đảm bảo tính bảo mật cho gói
tin. ESP cũng hỗ trợ tính năng cấu hình sử dụng trong tính huống chỉ cần bảo
mã hoá và chỉ cần cho authentication, nhưng sử dụng mã hoá mà không yêu cầu
xác thực không đảm bảo tính bảo mật. Không như AH, header của gói tin IP, bao
gồm các option khác. ESP thực hiện trên top IP sử dụng giao thức IP và mang
số hiệu 50 và AH mang số hiệu 51.
0 - 7 bit 8 - 15 bit 16 - 23 bit 24 - 31 bit
Security parameters index (SPI)
Sequence number

Payload data (variable)

Padding (0-255 bytes)

Pad Length Next Header
Authentication Data (variable)
Ý nghĩa của các phần:
Security parameters index (SPI) :Nhận ra các thông số được tích hợp với địa
chỉ IP.
Sequence number :Tự động tăng có tác dụng chống tấn công kiểu replay
attacks.
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:6
Bài tiểu luận môn: An toàn bảo mật thông tin
Payload data:Cho dữ liệu truyền đi
Padding:Sử dụng vài block mã hoá
Pad length:Độ lớn của padding.
Next header:Nhận ra giao thức được sử dụng trong quá trình truyền thông tin.
Authentication data :Bao gồm dữ liệu để xác thực cho gói tin.
1.7 Implementations - thực hiện
IPsec được thực hiện trong nhân với các trình quản lý các key và quá trình
thương lượng bảo mật ISAKMP/IKE từ người dùng. Tuy nhiên một chuẩn giao
diện cho quản lý key, nó có thể được điều khiển bởi nhân của IPsec.
Bởi vì được cung cấp cho người dùng cuối, IPsec có thể được triển khai trên
nhân của Linux. Dự án FreeS/WAN là dự án đầu tiên hoàn thành việc thực hiện
IPsec trong mã nguồn mở cụ thể là Linux. Nó bao gồm một nhấn IPsec stack
(KLIPS), kết hợp với trình quản lý key là deamon và rất nhiều shell scripts.
Dự án FreeS/WAN được bắt đầu vào tháng 3 năm 2004. Openswan
và strongSwan đã tiếp tục dự án FreeS/WAN. Dự án KAME cũng hoàn thành
việc triển khai sử dụng IPsec cho NetBSB, FreeBSB. Trình quản lý các
khoá được gọi là racoon. OpenBSB được tạo ra ISAKMP/IKE, với tên đơn giản
là isakmpd (nó cũng được triển khai trên nhiều hệ thống, bao gồm cả hệ thống
Linux).
1.8 Tổng quan về cách thức làm việc của Public Key Infrastructure (PKI).

Nếu bạn sử dụng Active Directory của công nghệ Windows NT thì mỗi user
khi được tạo ra cũng đi liền với nó có một cặp Key: Public key và Private key.
Ngoài ra còn có nhiều ứng dụng để tạo ra cặp khoá này.
Cặp key được tạo ra ngẫu nhiên với nhiều chữ số hiển thị. Khi các keys được
tạo ra từ nhiều chữ số ngẫu nhiên, sẽ không thể giải mã nếu ra private key nếu
biết public key. Nhưng có một số thuật toán có thể tạo ra public key từ private
key. Nhưng chỉ có Public key mới được published cho toàn bộ mọi người.
Hầu hết các cặp key được tạo ra từ nhiều số và bằng một thuật toán
mã hoá nào đó.
Một thông tin được mã hoá với public key thì chỉ có thể giải mã bởi private key.
Nếu chỉ có public key bạn sẽ không thể giải mã được gói tin. Điều này có nghĩa
khi một người gửi thông tin được mã hoá tới một người khác thì chỉ có người
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:7
Bài tiểu luận môn: An toàn bảo mật thông tin
nhận mới mở được thông tin đó mà thôi. Những người khác có bắt được toàn bộ
thông tin thì cũng không thể giải mã được nếu chỉ có Public key.
Một thông tin được mã hoá với private key có thể giải mã với public key. Khi
public key đã được public cho toàn bộ mọi người thì ai cũng có thể đọc được
thông tin nếu có public key.
Để đảm bảo an toàn hơn trong quá trình truyền thông tin: Alice kết hợp Private
key của cô ấy với Public key của Bob để tạo ra và chia sẻ bảo mật (share secret).
Cũng tương tự như vậy Bob cũng kết hợp Private key của mình với Public key
của Alice để tạo ra mọt shared secret. Rồi hai người truyền thông tin cho nhau.
Khi Alice truyền thông tin cho Bob bằng Shared Secret được tạo ra, khi Bob
nhận được gói tin mã hoá bởi shared secret đó dùng Public key của Alice kết hợp
với Private key của mình để mở thông tin. Điều này cũng tương tự khi Bob
truyền thông tin và cách Alice giải mã để lấy thông tin.
II. Các giao thức bảo mật SSL và TLS
2.1 - Lịch sử phát triển của giao thức SSL & TLS:
Như chúng ta đã biết có hai giao thức bảo mật quan trọng lớp vận chuyển

(Layer Transport) có tầm quan trọng cao nhất đối với sự bảo mật của các trình
ứng dụng trên Web: đó là hai giao thức SSL và TLS.
Nói chung, có một số khả năng để bảo vệ bằng mật mã lưu lượng dữ liệu
HTTP. Ví dụ, vào những năm 1990, tập đoàn CommerceNet đã đề xuất S-
HTTP mà về cơ bản là một cải tiến bảo mật của HTTP. Một phần thực thi của S-
HTTP đã làm cho có sẵn công cộng trong một phiên bản được chỉnh sửa của
trình duyệt Mosaic NCSA mà những người dùng phải mua (trái với trình duyệt
Mo NCSA "chuẩn" có sẵn công cộng và miễn phí trên Internet).
Tuy nhiên, cùng thời điểm Netscape Communication đã giới thiệu SSL
và một giao thức tương ứng với phiên bản đầu tiên của Netscape Navigator, Trái
với tập đoàn CommerceNet, Netscape Communications đã không tính phí các
khách hàng của nó về việc thực thi giao thức bảo mật của nó. Kết quả, SSL
trở thành giao thức nổi bật để cung cấp các dịch vụ bảo mật cho lưu lượng
dữ liệu HTTP 1994 và S-HTTP lặng lẽ biến mất.
Cho đến bây giờ, có ba phiên bản của SSL:
1. SSL 1.0: được sử dụng nội bộ chỉ bởi Netscape Communications. Nó chứa
một số khiếm khuyết nghiêm trọng và không bao giờ được tung ra bên ngoài.
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:8
Bài tiểu luận môn: An toàn bảo mật thông tin
2. SSL 2.0: được kết nhập vào Netscape Communications 1.0 đến 2.x. Nó có một
số điểm yếu liên quan đến sự hiện thân cụ thể của cuộc tấn công của đối tượng
trung gian. Trong một nỗ lực nhằm dùng sự không chắc chắn của công chúng về
bảo mật của SSL, Microsoft cũng đã giới thiệu giao thức PCT (Private
Communication Technology) cạnh tranh trong lần tung ra Internet Explorer đầu
tiên của nó vào năm 1996.
3. Netscape Communications đã phản ứng lại sự thách thức PCT của Microsoft
bằng cách giới thiệu SSL 3.0 vốn giải quyết các vấn đề trong SSL 2.0 và thêm
một số tính năng mới. Vào thời điểm này, Microsoft nhượng bộ và đồng
ý hỗ trợ SSL trong tất cả các phiên bản phần mềm dựa vào TCP/IP của nó (mặc
dù phiên bản riêng của nó vẫn hỗ trợ PCT cho sự tương thích ngược).

Thông số kỹ thuật mới nhất của SSL 3.0 đã được tung ra chính thức vào tháng
3 năm 1996. Nó được thực thi trong tất cả các trình duyệt chính bao gồm ví
dụ Microsoft Internet Explorer 3.0 (và các phiên bản cao hơn), Netscape
Navigator 3.0 (và các phiên bản cao hơn), và Open. Như được thảo luận ở phần
sau trong chương này, SSL 3.0 đã được điều chỉnh bởi IETF TLS WG. Thực tế,
thông số kỹ thuật giao thức TLS 1.0 dẫn xuất từ SSL 3.0. Hai phần tiếp theo tập
trung chỉ vào các giao thức SSL và TLS; giao thức PCT không được trình bầy
thêm trong các bài viết sắp tới.
2.2 - Cấu trúc của giao thức SSL:
Cấu trúc của SSL và giao thức SSL tương ứng được minh họa trong hình
1.1(Cấu trúc SSL và giao thức SSL). Theo hình này, SSL ám chỉ một lớp (bảo
mật) trung gian giữa lớp vận chuyển (Transport Layer) và lớp ứng dụng
(Application Layer). SSL được xếp lớp 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 1.1 minh họa một số giao thức ứng dụng điển hình bao gồm NSIIOP,
HTTP, FTP, Telnet, IMAP, IRC, và POP3. Tất cả chúng có thể được bảo vệ bằng
cách xếp lớn chúng 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.
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:9
Bài tiểu luận môn: An toàn bảo mật thông tin
Cấu trúc của SSL và giao thức SSL

Tóm lại, giao thức SSL cung cấp sự bảo mật truyền thông vốn có ba đặc tính cơ
bản:
1. Các bên giao tiếp (nghĩa là client và server) có thể xác thực nhau bằng cách sử
dụng mật mã khóa chung.
2. Sự bí mật của lưu lượng dữ liệu được bảo vệ vì nối kết được mã hóa trong
suốt sau khi một sự thiết lập quan hệ ban đầu và sự thương lượng khóa session
đã xảy ra.
3. Tính xác thực và tính toàn vẹn của lưu lượng dữ liệu cũng được bảo vệ vì các
thông báo được xác thực và được kiểm tra tính toàn vẹn một cách trong suốt
bằng cách sử dụng MAC.
Tuy nhiên, điều quan trọng cần lưu ý là SSL không ngăn các cuộc tấn công
phân tích lưu lượng. Ví dụ, bằng cách xem xét các địa chỉ IP nguồn và đích
không được mã hóa và các sô cổng TCP, hoặc xem xét lượng dữ liệu được
truyền, một người phân tích lưu lượng vẫn có thể xác định các bên nào đang
tương tác, các loại dịch vụ đang được sử dụng, và đôi khi ngay cả dành được
thông tin về các mối quan hệ doanh nghiệp hoặc cá nhân. Hơn nữa, SSL không
ngăn các cuộc tấn công có định hướng dựa vào phần thực thi TCP, chẳng hạn
như các cuộc tấn công làm tràn ngập TCP SYN hoặc cưỡng đoạt session.
Để 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).
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:10
Bài tiểu luận môn: An toàn bảo mật thông tin
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
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.2 và được minh họa một phần trong hình
1.1. Ngày nay, "S" chỉ định việc sử dụng SSL được thêm (hậu tố) nhất quán vào
các từ ghép của các giao thức ứng dụng tương ứng (trong một số thuật ngữ ban
đầu, S được sử dụng và được thêm tiền tố một cách không nhất quán và một
số từ ghép).
Bảng1.2: Các số cổng được gán cho các giao thức ứng dụng chạy trên
TLS/SSL.
Từ
khóa
Cổn
g
Mô tả
Nsiiop 261 Dịch vụ tên IIOP trên TLS/SSL

https 443 HTTP trên TLS/SSl
Smtps 465 SMTP trên TLS/SSL
Nntps 563 NNTP trên TLS/SSL
Ldaps 636 LDAP trên TLS/SSL
Ftps-data989 FTP (dữ liệu) trên TLS/SSL
Ftps 990 FTP (Điều khiển) trên TLS/SSL
Tenets 992 TELNET trên TLS/SSL
Imaps 994 IRC trên TLS/SSL
Pop3s 995 POP3 trên TLS/SSL
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:11
Bài tiểu luận môn: An toàn bảo mật thông tin

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.3. 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.4. 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.
Bảng 1.3 Các thành phần thông tin trạng thái Session SSL
Thành Phần Mô tả
Session ID Định danh được chọn bởi server để nhận dạng một
trạng thái session hoạt động hoặc có thể tiếp tục lại.
Peer certificate Chứng nhân X.509 phiên bản 3 của thực thể ngang
hàng.

Compression
method
Thuật toán dừng để nén dữ liệu trước khi mã hóa
Cipher spec Thông số của các thuật toán mã hóa dữ liệu
và MAC
Master secret Khóa mật 48-byte được chia sẻ giữa client
và server.
Is resumable Cờ vốn biểu thị session có thể được sử dụng để
bắt đầu các nối kết mới hay không.


Bảng 1.4 Các thành phần thông tin trạng thái nối kết SSL
Thành Phần Mô tả
Ngẫu nhiên
server và client
Các chuỗi byte được chọn bởi server và client cho
mỗi nối kết.
Khóa mật
MAC ghi
server
Khóa mật được sử dụng cho các hoạt động MAC
trên dữ liệu được ghi bởi server.
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:12
Bài tiểu luận môn: An toàn bảo mật thông tin
Khóa mật
MAC ghi
client
Khóa mật được sử dụng cho các hoạt động MAC
trên dữ liệu được ghi bởi client.
Khóa ghi

server
Khóa được sử dụng cho việc mã hóa dữ liệu
bởi server và giải mã bởi client
Khóa ghi clientKhóa được sử dụng để mã khóa dữ liệu bởi client
và giải mã bởi server.
Initialization
vector
Trạng thái khởi tạo cho một mật mã khối trong
chế độ CBC. Trường này được khởi tạo đầu tiên bởi
SSL Handshake Player. Sau đó, khối text mật
mã sau cùng từ mỗi bản ghi được dành riêng để
sử dụng vởi bản ghi sau đó.
Số chuỗi Mỗi phía duy trì các số chuỗi riêng biệt cho các
thông báo được truyền và được nhận cho mỗi nối
kết.

Như được minh họa trong hình 1.1, giao thức SSL gồm hai phần chính, SSL
Record Protocol và một số giao thức con SSL được xếp lớp trên nó:

- Record OK được xếp lớp trên một dịch vụ lớp vận chuyển định hướng nối kết
và đáng tin cậy, chẳng hạn như được cung cấp bởi TCP và cung cấp sự xác thực
nguồn gốc thông báo, sự bí mật dữ liệu và dữ liệu.
- Các dịch vụ toàn vẹn (bao gồm nhưng thứ như chống xem lại).
- Các giao thức con SSL được xếp lớp trên SSL Record Protocol để cung cấp sự
hỗ trợ cho việc quản lý session SSL và thiết lập nối kết.
Giao thức con SSL quan trọng nhất là SSL Handshake Protocol. Lần lượt giao
thức này là một giao thức xác thực và trao đổi khóa vốn có thể được sử dụng để
thương lượng, khởi tạo và đồng bộ hóa các tham số bảo mật và thông tin trạng
thái tương ứng được đặt ở một trong hai điểm cuối của một session hoặc nối kết
SSL.

2.3- SSL Record Protocol:
SSL Record Protocol nhận dữ liệu từ các giao thức con SSL lớp cao hơn
và xử lý việc phân đoạn, nén, xác thực và mã hóa dữ liệu. Chính xác hơn, giao
thức này lấy một khối dữ liệu có kích cỡ tùy ý làm dữ liệu nhập và tọa một loạt
các đoạn dữ liệu SSL làm dữ liệu xuất (hoặc còn được gọi là các bản ghi)
nhỏ hơn hoặc bằng 16,383 byte.
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:13
Bài tiểu luận môn: An toàn bảo mật thông tin

hình 1.5: Các bước SSL Record Protocol.



Các bước khác nhau của SSL Record Protocol vốn đi từ một đoạn dữ liệu
thô đến một bản ghi SSL Plaintext (bước phân đoạn), SSL Compressed (bước
nén) và SSL Ciphertext (bước mã hóa) được minh họa trong hình 1.5. Sau cùng,
mỗi bản ghi SSL chứa các trường thông tin sau đây:
• Loại nội dung;
• Số phiên bản của giao thức;
• Chiều dài;
• Tải trọng dữ liệu (được nén và được mã hóa tùy ý);
• MAC.

Loại nội dung xác định giao thức lớp cao hơn vốn phải được sử dụng để sau
đó xử lý tải trọng dữ liệu bản ghi SSL (sau khi giải nén và giải mã hóa thích
hợp).
Số phiên bản của giao thức xác định phiên bản SSL đang sử dụng (thường là
version 3.0)
Mỗi tải trọng dữ liệu bản ghi SSL được nén và được mã hóa theo phương thức
nén hiện hành và thông số mật mã được xác định cho session SSL.

Lúc bắt đầu mỗi session SSL, phương pháp nén và thông số mật mã thường
được xác định là rỗng. Cả hai được xác lập trong suốt quá trình thực thi ban đầu
SSL Handshake Protocol. Sau cùng, MAC được thêm vào mỗi bản ghi SSL. Nó
cung cấp các dịch vụ xác thực nguồn gốc thông báo và tính toàn vẹn dữ liệu.
Tương tự như thuật toán mã hóa, thuật toán vốn được sử dụng để tính và xác
nhận MAC được xác định trong thông số mật mã của trạng thái session hiện
hành. Theo mặc định, SSL Record Protocol sử dụng một cấu trúc MAC vốn
tương tự nhưng vẫn khác với cấu trúc HMAC hơn. Có ba điểm khác biệt chính
giữa cấu trúc SSL MAC và cấu trúc HMAC:
1. Cấu trúc SSL MAC có một số chuỗi trong thông báo trước khi hash để ngăn
các hình thức tấn công xem lại riêng biệt.
2. Cấu trúc SSL MAC có chiều dài bản ghi.
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:14
Bài tiểu luận môn: An toàn bảo mật thông tin
3. Cấu trúc SSL MAC sử dụng các toán tử ghép, trong khi cấu trúc MAC sử
dụng moduloe cộng 2.
Tất cả những điểm khác biệt này hiện hữu chủ yếu vì cấu trúc SSL MAC
được sử dụng trước cấu trúc HMAC trong hầu như tất cả thông số kỹ thuật giao
thức bảo mật Internet. Cấu trúc HMAC cũng được sử dụng cho thông
số kỹ thuật giao thức TLS gần đây hơn.
Như được minh họa trong hình 1.5, một số giao thức con SSL được xếp lớp
trên SSL Record Protocol. Mỗi giao thức con có thể tham chiếu đến các loại
thông báo cụ thể vốn được gửi bằng cách sử dụng SSL Record Protocol. Thông
số kỹ thuật SSL 3.0 xác định ba giao thức SSL sau đây:
• Alert Protocol;
• Handshake Protocol;
• ChangeCipherSpec Protocol;
Tóm lại, SSL Alert Protocol được sử dụng để chuyển các cảnh báo thông qua
SSL Record Protocol. Mỗi cảnh báo gồm 2 phần, một mức cảnh báo và một mô
tả cảnh báo.

SSL Handshake Protocol là giao thức con SSL chính được sử dụng để hỗ trợ
xác thực client và server và để trao đổi một khóa session. Do đó SSL Handshake
Protocol trình bày tổng quan và được thảo luận trong phần tiếp theo.
Sau cùng, SSL ChangeCipherSpec Protocol được sử dụng để thay đổi giữa
một thông số mật mã này và một thông số mật mã khác. Mặc dù thông số mật mã
thường được thay đổi ở cuối một sự thiết lập quan hệ SSL, nhưng nó cũng có thể
được thay đổi vào bất kỳ thời điểm sau đó.
Ngoài những giao thức con SSL này, một SSL Application Data Protocol
được sử dụng để chuyển trực tiếp dữ liệu ứng dụng đến SSL Record Protocol.
2.4 - SSL Handshake Protocol:
SSL Handshake Protocol là giao thức con SSL chính được xếp lớp trên SSL
Record Protocol. Kết quả, các thông báo thiết lập quan hệ SSL được cung cấp
cho lớp bản ghi SSL nơi chúng được bao bọc trong một hoặc nhiều bản ghi SSL
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
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:15
Bài tiểu luận môn: An toàn bảo mật thông tin
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]
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:
- 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ợ.
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:16
Bài tiểu luận môn: An toàn bảo mật thông tin
- 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 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
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:17

Bài tiểu luận môn: An toàn bảo mật thông tin
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
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:18
Bài tiểu luận môn: An toàn bảo mật thông tin
của người dùng đến server ở bước 3. Tiếp theo, client gởi một thông báo
CLIENTKEYEXCHANGE có dạng phụ thuộc vào thuật toán cho mỗi
khóa được chọn bởi server:
- Nếu RSA được sử dụng cho việc xác thực server và trao đổi khóa, client tạo
một khóa mật 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ảu
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
Sinh viên thực hiện:Nguyễn Thị Luyên Trang:19
Bài tiểu luận môn: An toàn bảo mật thông tin
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à 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 dung.

Sinh viên thực hiện:Nguyễn Thị Luyên Trang:20
Bài tiểu luận môn: An toàn bảo mật thông tin
KẾT LUẬN
Qua quá trình tìm hiểu em biết được việc truyền tải thông tin cần phải đảm
bảo an toàn trong đó thi an toàn đường truyền góp phần đảm bảo tính toàn vẹn
của dữ liệu truyền đi
Các phương thức tấn công qua mạng ngày càng tinh vi, phức tạp có thể gây ra
mất mát thông tin, thậm chí có thể làm suy sụp toàn bộ hệ thống thông rin của
doanh nghiệp. Vì vậy an toàn và bảo mật thông tin là nhiệm vụ rất quan trọng
trong đó phải đảm bảo ở các bước:
• Đảm bảo an toàn thông tin tại máy chủ
• Đảm bảo an toàn thông tin cho phía máy trạm
• Bảo mật thông tin trên đường truyền
Do vậy nhu cầu của an toàn thông tin đặt ra cho việc sử dụng mạng
và truyền thông đòi hỏi phải có các phương tiện bảo vệ dữ liệu khi
truyền.

Sinh viên thực hiện:Nguyễn Thị Luyên Trang:21