Mục Lục : Trang

1- Giới thiệu sơ lược về SSL/TLS: 2

2- Ứng dụng: 3
3- Bảo mật: 3
4- Cách viết mật mã (Cryptography) : 4
5- Mã hóa khóa đối xứng( secret key): 4
6- Mã hóa không đối xứng(Asymmetric key encryption): 5
7- Bảng tóm tắt(Digests): 6
8- Chứng chỉ( Certificates): 6
9- Lỗ hổng bảo mật của SSL: 7
A- Hướng tấn công số 1 : 8
B- Hướng tấn công số 2 : 9
C- Hướng tấn công số 3 : 11

1
1-Giới thiệu sơ lược về SSL/TLS:
SSL (Secure Socket Layer) là giao thức được phát triển bởi
Netscape.Version 1.0 không được công khai, version 2.0 được phát hành
tháng 2 năm 1995 nhưng vẫn có nhiều lỗ hổng về bảo mật nên SSL version
3.0 được phát hành vào năm 1996.
SSL: là một giao thức sử dụng rộng rãi cho truyền đạt thông tin trong
mạng.Giao thức SSL dự phòng dịch vụ tiếp theo cho ứng dụng của mạng:
Data privacy: Client/Server session thành các mật mã.
Client authentication: Server có thể kiểm tra sự đồng nhất của Client.
Server authentication: Client có thể kiểm tra sự đồng nhất của Server.
Message integrity(tính nguyên vẹn của gói tin) : Data không thể sửa
trong khi truyền.
TLS 1.0 (Transport Layer Security) lần đầu tiên được định nghĩa trong RFC
2246 trong Tháng 1 năm 1999 như là một nâng cấp từ SSL v3.0. Như đã nêu
trong RFC, sự khác biệt này giữa các giao thức SSL 3.0 là không đáng kể..Nó
dùng nhiều các thuật toán “cryptographic”.
TLS v1.1 đã được cập nhật từ v 1.0 trong RFC 4346 trong tháng 4 năm 2006.
Phiên bản này có 1 số khác biệt:
Được bảo vệ chống lại tấn công Cipher Block Chaining (CBC).
Khởi tiềm ẩn Initialization Vector (IV) đã được thay thế bằng một IV rõ
ràng.
Thay đổi trong giải quyết các lỗi padding.
Hỗ trợ cho IANA đăng ký của các thông số.
TLS v1.2 được cập nhật trong RFC 5246 tháng 4 ,2008. Phiên bản này dựa
trên những đặc điểm kỹ thuật của v1.1, sự khác biệt lớn bao gồm:
Sự kết hợp MD5/SHA-1 trong PseudoRandom Function (PRF) đã được
thay thế bằng những thuật toán mật mã-bộ-PRFs định.
Sự kết hợp MD5/SHA-1 trong kỹ thuật số các nguyên tố đã ký được
thay thế bằng một băm duy nhất, xác định trong một lĩnh vực mới.
Nâng cao tại các khách hàng và khả năng của máy chủ để xác định
những thuật toán băm và chữ ký của họ sẽ chấp nhận.
Mở rộng hỗ trợ cho sự mật mã xác thực.
Mở rộng định nghĩa TLS và Advanced Encryption Standard (AES)
CipherSuites được thêm vào.

2-Ứng dụng:

2
 Trong các ứng dụng thiết kế, TLS thường được thực hiện trên đầu trang
của bất kỳ giao thức vận tải tầng nào, đóng gói ứng dụng giao thức cụ thể như
HTTP, FTP, SMTP, NNTP, và XMPP.
Một sử dụng nổi bật của TLS là để bảo vệ World Wide Web lưu lượng vận
chuyển bằng HTTP để hình HTTPS. Đáng chú ý là các ứng dụng thương mại
điện tử và quản lý tài sản. Ngày càng nhiều, các Simple Mail Transfer
Protocol (SMTP) cũng được bảo vệ bởi TLS (RFC 3207). Các ứng dụng này
sử dụng giấy chứng nhận công chính để xác minh nhận dạng của thiết bị đầu
cuối.
TLS có một số lợi thế vốn có trong tường lửa và NAT traversal mà làm cho nó
dễ dàng hơn để quản trị cho quần thể truy cập lớn từ xa .
TLS cũng là một phương pháp tiêu chuẩn để bảo vệ Session Initiation
Protocol (SIP) ứng dụng tín hiệu. TLS có thể được sử dụng để cung cấp chứng
thực và mã hoá của tín hiệu SIP kết hợp với VoIP và SIP khác dựa trên ứng
dụng .
3- Bảo mật:
TLS / SSL có một loạt các biện pháp bảo mật:
Các khách hàng có thể sử dụng quyền hạn của giấy chứng nhận (CA's)
khóa công khai để xác nhận chữ ký số của CA trên chứng chỉ máy chủ. Nếu
các chữ ký số có thể được xác minh, khách hàng chấp nhận chứng chỉ máy
chủ như là một chứng chỉ hợp lệ phát hành bởi một CA tin cậy.
Các khách hàng xác minh rằng CA phát hành là vào danh sách các CAs tin
cậy.
Các khách hàng sẽ kiểm tra giấy chứng nhận thời gian hiệu lực của máy
chủ. Quá trình thẩm định dừng lại nếu ngày hiện tại và thời gian vượt quá thời
hạn hiệu lực.
Đánh số tất cả các bản ghi ứng dụng với một trình tự và sử dụng dãy số
này trong Message Authentication Codes (MACs).
Một gói thư trao đổi thông tin kết thúc bắng việc bắt tay trả lời “Finished”
giữa cả hai đối tượng trao đổi thông tin với nhau.
Một hàm ngẫu nhiên chia dữ liệu đầu vào ra một nửa và mỗi một bộ xử lý
với độ khó hàm hashing(MD5 và SHA-1), thì XORs của chúng sẽ cùng nhau
tạo MAC.Chúng sẽ có bảo vệ dự phòng nếu thuật toán ở đây có thể bị công
kích được.
SSL v3 được cải tiến trên SSLv2 nhờ được thêm vào cơ sở mã hóa của
SHA-1,và nâng cấp them xác thực của chứng chỉ(CA).Cải tiến thêm trong
SSLv3 bao gồm luồng giao thức bắt tay và tăng thêm việc chống đỡ lại việc
tấn công “man-in-the-middle”
4-Cách viết mật mã (Cryptography) :

3
 Mật mã là thuật ngữ ám chỉ để chuyển một thông điệp mà chỉ có người
nhận mới có thể độc tin nhắn. Mật mã học cũng được sử dụng để xác minh
người gửi tin nhắn, và để xác minh một tin nhắn không được sửa đổi trong
quá trình truyền.
SSL sử dụng thuật toán mã hóa khác nhau để đảm bảo thông tin liên lạc
an toàn. Có bốn khái niệm mã hóa được sử dụng bởi SSL:
Mã hóa khóa đối xứng( khóa bí mật)
Mã hóa khóa không đối xứng(khóa công cộng)
Gói tin vắn tắt và chữ kí điện tử
Chứng chỉ
5-Mã hóa khóa đối xứng( secret key)
Khoá mật mã đối xứng sử dụng một chìa khóa duy nhất cho cả hai mã hóa
và giải mã dữ liệu.Như thể hiện trong hình bên dưới các gói tin “plain text”
đơn giản là thông qua các thuật toán mã hóa “ciphertext”, chúng không thể
đọc, và do đó an toàn. Kết quả là thông tin an toàn đến người nhận.Những
người nhận giải mã thông điệp trở lại “plaintext” bằng cách sử dụng cùng một
khóa.

4
 Thuật toán mã hóa đối xứng có hai loại: mã hóa khối và mã hóa luồng.
Mã hóa khối theo truyền thống phổ biến nhất. Chúng hoạt động bằng cách
chia dữ liệu thành các khối có kích thước cố định, và sau đó mã hóa từng khối
riêng. Phần dữ liệu còn lại độ dài của “plaintext” là nhiều khối mật mã cùng
kích thước.Ngược lại, thuật toán mã hóa luồng được mã hóa bằng bộ phát các
số ngẫu nhiên. Họ sử dụng một hạt giống bắt đầu từ một chìa khóa để sản xuất
một dòng các bit ngẫu nhiên được gọi là keystream này. Để mã hóa dữ liệu,
một trong những có các chữ thô và đơn giản XORs nó với keystream này.
Bảo mật của mã hóa khóa đối xứng phụ thuộc vào kích thước của khóa.
Khóa càng lớn, càng có nhiều khó khăn cho kẻ đột nhập để phá vỡ mật mã.
Tuy nhiên, khóa dài còn mất nhiều thời gian để cho người nhận giải mã, và có
thể dẫn đến sự xuống cấp hiệu suất.
6-Mã hóa không đối xứng(Asymmetric key (public key)
encryption)
Trong mã hóa không đối xứng,một cặp khóa bao gồm 1 “public key” và 1
“private key” để mã hóa và giải mã dữ liệu. Các “public key” công khai,
nhưng không thể được sử dụng để giải mã. Chỉ có “private key” có thể giải
mã dữ liệu. Ngoài ra, “private key” có thể được dùng để mã hóa dữ liệu.

5
 Một vấn đề lớn với mật mã khóa riêng là làm thế nào hai máy quyết định
về một khóa riêng an toàn. Đối với các trang web thương mại điện tử như
amazon.com, bạn không thể gán khóa riêng để mỗi khách hàng có thể trước.
Mật mã hóa khóa công khai giải quyết vấn đề này.Một khách hang gửi dữ liệu
được mã hóa đến server sử dụng khóa công khai để mã hóa.Vì vậy, bất kỳ
khách hàng có thể giao tiếp an toàn với các máy server.
Giải mã khóa bí mật là nhanh hơn nhiều để thực hiện trên một máy tính
hơn so với giải mã khóa công khai.Trong thực tế chúng được sử dụng với
nhau,do đó một khóa công khai được sử dụng để mã hóa một khóa bí mật
được tạo ngẫu nhiên,và khóa bí mật được sử dụng để mã hóa thông điệp thực
tế.Đây được gọi là mã hóa “hybrid”, và được sử dụng bởi các giao thức SSL.
7-Bảng tóm tắt(Digests)
Bảng tóm tắt sử dụng để đảm bảo rằng một gói tin là hợp lệ và không bị
sửa đổi trong quá trình truyền.Một bảng tóm tắt ngắn,thường khoảng 128
bit.Bản tóm tắt được tạo ra bằng các áp dụng một hàm băm(hash) trên gói tin
gốc.Rất khó để có thể tìm ra 2 gói tin có bảng tóm tắt giống nhau.
Cả hai gói tin và bảng tóm tắt được mã hóa và gửi đến người nhận.Sau khi
giải mã ,người nhận kiểm tra bảng tóm tắt của gói tin và so sánh với bảng tóm
tắt nhận được để đảm bảo toàn vẹn thông điệp. Nếu kẻ xâm nhập một sửa đổi
trong quá trình truyền dữ liệu đã được mã hóa, có khả năng là các dữ liệu giải
mật mã sẽ không có một bảng tóm tắt hợp lệ.
8-Chứng chỉ( Certificates)
Một chứng chỉ là một tập tin được sử dụng để xác định sự an toàn.Một
chứng chỉ thì bao gồm các thông tin:
Tên máy tính
Tổ chức / công ty
Vị trí của máy (thành phố, tiểu bang và quốc gia)
Khung thời gian giấy chứng nhận là hợp lệ
Khóa công khai / khóa riêng để liên lạc an toàn
Giấy chứng nhận quyền tên
Giấy chứng nhận quyền chữ ký
Các khoá công khai cho phép máy này giao tiếp một cách an toàn với các máy
khác. Các công ty và địa điểm cung cấp thông tin về máy.

Đây là minh họa giai đoạn Authentication của 1 phiên SSL

6
9- Lỗ hổng bảo mật của SSL:
SSL (Secure Sockets Layer) là giao thức dùng để đảm bảo an toàn cho
thông tin liên lạc trên Internet. Các nhà nghiên cứu đã tiết lộ một số kiểu tấn
công có thể được dùng để làm thương tổn việc trao đổi thông tin an toàn giữa
website và trình duyệt (tấn công có thể cho phép tin tặc đánh cắp mật khẩu,
chiếm đoạt 1 phiên giao dịch ngân hàng trực tuyến hay thậm chí là đưa ra một
bản cập nhật trình duyệt Firefox có chứa mã độc). Vấn đề nằm trong cách
nhiều trình duyệt thực thi SSL và trong hệ thống hạ tầng khóa công khai
X.509 (dùng để quản lý các chứng thức số được SSL sử dụng để quyết định
xem website có đáng tin cậy hay không).
Nhà nghiên cứu bảo mật có nickname là Moxie Marlinspike giới thiệu
kiểu tấn công “null-termination certificate” làm gián đoạn phiên duyệt SSL
giữa client và server (trong kiểu tấn công này, nếu viết
“www.paypal.com\0.thoughtcrime.org” sẽ được hiểu thành
“www.paypal.com”). Loại tấn công kiểu “man-in-the-middle” này không thể
phát hiện được, nếu lan rộng sẽ ảnh hưởng tới Internet Explorer, Firefox 3.0,
phần mềm mạng riêng ảo VPN (virtual private network), các trình e-mail
client và IM (instant messaging). Để bịt lỗ hổng này thì cần cập nhật, sửa chữa
cho hệ thống X.509.

7
 Tổng quan thì lỗ hổng này nằm ở sự thiếu "ăn rơ" giữa TLS/SSL và các
protocol trên nó như HTTP hay SMTP. Khai thác lỗ hổng này thì kẻ tấn công
có thể chèn thêm một đoạn plaintext bất kỳ vào TLS/SSL encrypted
stream giữa client và server mà cả client và server đều không thể phát
hiện được.
Giả định:
• Ngân hàng A có cung cấp dịch vụ Internet Banking ở địa chỉ
https://www.ebank.com. Máy chủ của của họ chạy phần mềm có lỗ
hổng mà chúng ta đang bàn ở đây. Chúng ta gọi máy chủ này là server.

* Để tăng cường an ninh, ngân hàng A yêu cầu khi khách hàng (gọi là
client) sử dụng các tính năng có liên quan đến giao dịch tài chính nằm
trong khu vực https://www.ebank.com/account/, thì (browser của) họ
phải có cài đặt client certificate cho ngân hàng A cung cấp. Lưu ý là
nhiều ngân hàng ở VN thực hiện cái này lắm nha.

* Ngoài ra ngân hàng A còn hỗ trợ khách hàng truy cập bằng (Safari
trên) iPhone, lúc đó khách hàng sẽ được chuyển đến
https://www.ebank.com/iphone/. Do iPhone có processor yếu, nên ngân
hàng A cấu hình máy chủ web của họ để sử dụng một bộ ciphersuite
yếu hơn bộ ciphersuite mà họ sử dụng cho các khách hàng thông
thường.
Có thể lợi dụng tấn công các khách hàng của ngân hàng A theo 3 hướng tấn
công mà các tác giả nêu ra. Àh lưu ý là đây là loại tấn công MITM, nghĩa là
attacker phải có quyền theo dõi, điều chỉnh dữ liệu truyền qua lại giữa client
và server. Attacker có thể làm việc này thông qua các tấn công vào các giao
thức ARP hay DNS.

A-Hướng tấn công số 1 :

* Bước 1: client truy cập vào https://www.ebank.com. Lúc này client sẽ kết
nối đến attacker, và gửi CLIENT_HELLO để bắt đầu giao thức TLS/SSL.
Attacker sẽ tạm dừng cái kết nối này và lưu msg CLIENT_HELLO lại để
dùng trong bước 3.

* Bước 2: attacker mở kết nối đến server thật. Hai bên sẽ bắt tay theo giao
thức TLS/SSL để tạo thành một session. Sau khi hoàn tất bắt tay, attacker gửi
một HTTP request, đại loại như:

POST /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n

8
* Bước 3: server thấy có một request đến khu vực /account/ nên nó tạm thời
dừng xử lý request này lại và như đã nói ở trên, nó yêu cầu attacker phải đưa
client certificate cho nó xem. Cái hay ở đây, mặc dầu attacker không có
(private key của) certificate của client, nhưng hắn vẫn có thể *proxy* cái
certificate đó từ client lên server, mà không bị bên nào phát hiện cả.

Server bắt đầu quá trình xác thực bằng việc gửi một msg HELLO_REQUEST
ngược lại cho attacker. Attacker nhận được msg này thì hắn gửi
CLIENT_HELLO mà hắn đã lưu ở bước 1 ngược lại cho server. Rồi cứ thế,
attacker đứng giữa, chuyển msg qua lại giữa client và server cho đến khi quá
trình xác thực bằng client certificate kết thúc thành công.

Lưu ý là có 2 loại msg mà attacker sẽ gửi. Loại thứ nhất là những msg mà hắn
phải giải mã/mã hóa trước khi gửi đi. Ví dụ như hắn nhận "Certificate" từ phía
client thì hắn sẽ mã hóa cái msg này lại, rồi mới gửi cho server. Loại thứ hai là
những msg mà hắn không đọc được (vì không có key), hắn chỉ làm mỗi việc
là nhận từ client thì gửi qua server và ngược lại.

* Bước 4: quá trình xác thực client certificate đã kết thúc thành công, server
tiếp tục xử lý cái request của attacker ở trên, và trả kết quả lại cho attacker
(lưu ý là attacker sẽ không đọc được kết quả này).

Điểm yếu là ở đây. Như chúng ta thấy, khi attacker gửi request ở bước 3, lúc
đó hắn chưa được xác thực. Nói cách khác, lúc này request của hắn là
unauthenticated request. Việc xác thực diễn ra sau đó, và sau khi xác thực rồi
thì server lại quay lại xử lý tiếp cái unauthenticated request của attacker.

Lưu ý, ở bước này, để tránh bị tình nghi, attacker có thể tiếp tục trả kết quả về
cho client để đóng kết nối lại một cách êm đẹp.

B-Hướng tấn công số 2 :

tất cả 3 hướng tấn công này đều hướng đến chôm credential của client để
gửi các authenticated request đến server. Credential ở đây có thể là
certificate (như ở hướng số 1) hay cookie/session (như ở hướng số 2 và số
3). Nếu chỉ áp dụng cho HTTPS, nhìn ở một góc độ nào đó, các hướng tấn
công này rất giống với tấn công CSRF(Cross Site Request Forgery). Nên nếu
ứng dụng của bạn đã có các phương thức phòng chống CSRF rồi hay nếu ứng
dụng của bạn không chấp nhận thay đổi state bằng GET, thì tạm thời cũng
không phải có gì lo lắng.

9
Đối với hướng số 1, lợi dụng client certificate để gửi một authenticated
request. Ở trường hợp các server không xác thực bằng certificate sẽ sử dụng
hướng tấn cống số 2.

Hướng tấn công này cũng có 4 bước:

* Bước số 1: tương tự như hướng tấn công số 1.

* Bước 2: attacker mở kết nối đến server thật. Hai bên sẽ bắt tay theo giao
thức TLS/SSL để tạo thành một session.

Sau khi hoàn tất bắt tay, attacker gửi một HTTP request, đại loại như:
GET /iphone/login HTTP/1.1\r\n
Host: ebank.com\r\n
Connection: keep-alive\r\n
\r\n
GET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n
Host: ebank.com\r\n
Connection: close\r\n
X-ignore-this:

* Bước số 3: server thấy có request đến /iphone/ nên nó tạm thời dừng xử lý
request này lại và, như đã nói ở phần giả định, server sẽ bắt đầu quá trình
renegotiate lại để chọn một bộ ciphersuite yếu hơn. Vấn đề ở đây là server sẽ
buffer lại toàn bộ nhóm unauthenticated request này, khi mà renegotiate xong
thì lại quay lại xử lý hết tất cả.

Trong quá trình renogotiation, vai trò của attacker cũng tương tự như ở bước
số 3 của hướng tấn công số 1, nghĩa là hắn cũng chỉ *proxy* msg qua lại giữa
client và server, cho đến khi quá trình renegotiate kết thúc thành công.

* Bước số 4: lúc này, client thấy đã handshake xong rồi, nên bản thân nó sẽ
gửi tiếp cái HTTP request của nó ở dạng:

GET /index HTTP/1.1\r\n

Cookie: AuthMe=Now\r\n
\r\n
Chuyện bất ngờ diễn ra ở đây. Server nó sẽ gom nhóm unauthenticated
request ở bước 2 (do attacker gửi) và cái authenticated request này (do client
gửi) rồi xử lý chung một lần. Nguyên nhân server xử lý như thế là do cái cờ
keep-alive ở request đầu tiên. Thành ra lúc này nhóm request trở thành như

10
sau (màu cam là attacker gửi, màu xanh là client gửi):

GET /iphone/login HTTP/1.1\r\n

Host: ebank.com\r\n
Connection: keep-alive\r\n
\r\n
GET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n
Host: ebank.com\r\n
Connection: close\r\n
X-ignore-this:GET /index HTTP/1.1\r\n
Cookie: AuthMe=Now\r\n
\r\n

Ở đây cái header X-ignore-this đã vô hiệu hóa cái request GET /index
HTTP/1.1 của client, đồng thời chôm luôn cookie của client để gắn vào cái
unauthenticated request GET /account/transfer?
amount=1000&receiver=attacker. Rất hay!

C- Hướng tấn công số 3 :

Đây là hướng tấn công mạnh nhất, không cần server phải có cấu hình đặc biệt
gì để thực hiện. Sự khác biệt cơ bản giữa tấn công này với hai hướng tấn công
vừa rồi là trong trường hợp này, client bắt đầu quy trình renegotiation.

Ý tưởng thực hiện tấn công rất giống với hướng 2, chỉ khác nhau ở bước số 2,
attacker sẽ không gửi GET /iphone/login nữa mà gửi trực tiếp luôn request
của hắn, kèm theo một cái "X-ignore-this" header.

Ngay sau khi gửi cái request đó, attacker sẽ forward cái CLIENT_HELLO thu
được ở bước 1 sang cho phía server để bắt đầu quy trình renegotiation. Khi đã
renegotiate xong, client sẽ gửi request ban đầu của mình đến server, lúc này
toàn bộ request sẽ trông như sau (phần màu cam của attacker gửi, phần màu
xanh của client gửi):

GET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n

Host: ebank.com\r\n
Connection: close\r\n
X-ignore-this: GET /index HTTP/1.1\r\n
Cookie: AuthMe=Now\r\n
\r\n

11
Tương tự ở trên, X-ignore-this đã vô hiệu hóa request của client và chôm
cookie để biến request của attacker thành authenticated. Không cần keep-
alive, không cần server phải có cấu hình đặc biệt gì cả!

http://en.wikipedia.org/wiki/Transport_Layer_Security
http://www.instantssl.com/ssl-certificate-products/what_is_ssl.html
http://www.safescrypt.com/faq/faqsslbasics.html#Top
http://www.visolve.com/security/ssl_intro.php
http://www.vnsecurity.net/t/tls/
“SSL and TLS Essentials” – Securing the Web –Stephen Thomas

12