Bài Báo cáo

Môn:An Ninh Internet

K13TMT - Nhóm 4

Đề tài: Tìm hiểu giao thức

SSL/TLS – Hoạt động, tấn công và
phòng chống.
Nhóm 3 – Phân chia công việc

Tên thành viên Công việc

Dương Thanh Hoài Bão
Lê Văn Trọng Tìm và tổng hợp tài liệu
Nguyễn Viết Tài
Nguyễn Văn Tân
Viết báo cáo phần 2, 3
Lê Quang Hiển
Lê Nguyễn Quang Minh Viết báo cáo phần 1,2
Nguyễn Thanh Long Trình bày slide
 Tìm hiểu SSL/TLS
Nội dung trình bày

Phần 1 Tổng quan về giao thức SSL/TLS

Phần 2 Cấu trúc và cách làm việc của SSL/TLS

Phần 3 Tấn công và cách phòng chống

 Tìm hiểu SSL/TLS

Phần 1 Tổng quan về giao thức SSL/TLS

SSL/TLS là gì ?
• Secure Sockets Layer (SSL), Transport Layer
Security (TLS) là hai giao thức nổi bật để cung
cấp dịch vụ bảo mật cho lưu lượng dữ liệu trên
kênh truyền.
• Lợi ích khi dùng SSL/TLS :
Strong authentication, message privacy, and integrity.
Interoperability
Algorithm flexibility
Ease of deployment
Ease of use
Lịch sử ra đời SSL/TLS
• SSL được phát triển bởi Netscape Communications Corporation vào
năm 1994 để đảm bảo các giao dịch trên World Wide Web.
• Đến nay đã có 3 phiên bản SSL:
 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
 SSL 2.0: Ra đời cùng lúc Microsoft giới thiệu giao thức PCT
(Private Communication Technology) , nhằm cạnh tranh trong lần
tung ra Internet Explorer đầu tiên vào năm 1996.
 SLL 3.0: 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).
Lịch sử ra đời SSL/TLS
• Ngay sau đó, IETF (Internet Engineering Task
Force) đã bắt đầu làm việc để phát triển một
giao thức chuẩn để cung cấp các chức năng
tương tự  TLS ra đời.
• TLS 1.0 được IETF phát triển dựa trên SSL 3.0

• TLS được thông tin chi tiết trong RFC 2246.

SSL vs TLS
• SSL sử dụng giải thuật MAC (Message Authentication Code)
• TLS sử dụng giải thuật HMAC (Hashing for Message
Authentication Code)
MAC và HMAC là hai phương thức bảo đảm tính toàn vẹn của dữ liệu
khi truyền trong môi trường không tin cậy như Internet. HMAC có thêm
các giải thuật băm.
• TLS được chuẩn hóa trong RFC 2246
• TLS được đính thêm mới một số thông điệp cảnh báo (alert
message)
• TLS bao gồm thêm giải thuật Fortezza (giải thuật này không
được công bố bởi các chính sách của IETF)
Các dịch vụ dùng SSL/TLS sử dụng các số cổng chuyên dụng
được dành riêng bởi IANA - Internet Asigned Numbers
Authority
Dịch vụ Cổng Mô tả Dịch vụ Cổng
Dịch vụ tên IIOP trên
Nsiiop 261 Nsiiop 261
TLS/SSL

https 443 HTTP trên TLS/SSl https 443

Smtps 465 SMTP trên TLS/SSL Smtps 465

Nntps 563 NNTP trên TLS/SSL Nntps 563

Ldaps 636 LDAP trên TLS/SSL Ldaps 636

Ftps-data 989 FTP (dữ liệu) trên TLS/SSL Ftps-data 989

FTP (Điều khiển) trên

Ftps 990 Ftps 990
TLS/SSL
 Tìm hiểu SSL/TLS

Phần 2 Cấu trúc và cách làm việc của SSL/TLS

Cấu trúc giao thức SSL/TLS

• Gồm 2 phần chính :

TheHandshake protocols layer.
Record layer
The Handshake protocols layer
Các giao thức ở lớp này chịu trách nhiệm
establishing hoặc resuming các secure session.
Và các mục tiêu chính là:
• Negotiate cipher suites and compression algorithms.
• Authenticate the server to the client and, optionally,
authenticate the client to the server through certificates
and public or private keys.
• Exchange random numbers and a pre-master secret.
Together with some further data, these values will be
used to create the shared secret key that the Record
Layer will use to hash and encrypt application data. The
shared secret key is called the Master Secret.
The three Handshake sub-protocols
• Handshake : Thương lượng/Thỏa thuận các
thông tin về phiên kết nối.
• Change Cipher Spec : thay đổi bộ khóa đang
dùng hoặc thông báo về việc sử dụng bộ mật
mã mới.
• Alert : Dùng alert message để chỉ ra trạng thái
hoặc cảnh báo lỗi trong phiên truyền.
Handshake Protocol Functions
The Handshake protocol provides a number of
very important security functions. It performs a
set of exchanges that starts authentication and
negotiates the encryption, hash, and
compression algorithms.
Handshake Protocol Functions
Authentication
• A certificate is a digital form of identification that is usually issued by a
certification authority (CA) and contains identification information, a
validity period, a public key, a serial number, and the digital signature of the
issuer.
• For authentication purposes, the Handshake Protocol uses an X.509
certificate to provide strong evidence to a second party that helps prove the
identity of the party that holds the certificate and the corresponding private
key.
• A CA is a mutually trusted third party that confirms the identity of a
certificate requestor (usually a user or computer), and then issues the
requestor a certificate. The certificate binds the requestor’s identity to a
public key. CAs also renew and revoke certificates as necessary. For
example, if a client is presented with a server’s certificate, the client
computer might try to match the server’s CA against the client’s list of
trusted CAs. If the issuing CA is trusted, the client will verify that the
certificate is authentic and has not been tampered with. Finally, the client will
accept the certificate as proof of identity of the server.
Handshake Protocol Functions
Encryption : There are two main types of
encryption:
• Symmetric Key, also known as Private Key.
Typical algorithms include Data Encryption Standard (DES), Triple
DES (3-DES), RC2, RC4, and Advanced Encryption Standard (AES).

• Asymmetric Key, also known as Public Key.

The most common algorithm is Rivest, Shamir, and Adleman (RSA).

 TLS/SSL uses symmetric key for bulk encryption

and public key for authentication and key
exchange.
Handshake Protocol Functions
Hash Algorithms : During the handshake process,
the client and server agree on the hash algorithm.
• A hash is a one-way mapping of values to a smaller
set of representative values, so that the size of the
resulting hash is smaller than the original message
and the hash is unique to the original data.
• A hash is similar to a fingerprint: a fingerprint is
unique to the individual and is much smaller than
the original person.
• Hashing is used to establish data integrity during
transport. Two common hash algorithms are Message Digest 5 (MD5) and
Standard Hash Algorithm 1 (SHA-1). MD5 produces a 128-bit hash value and
SHA-1 produces a 160-bit value.
Record Layer
 The Record Protocol receives and encrypts
data from the application layer and delivers it to
the Transport Layer. Then it takes the data,
fragments it to a size appropriate to the
cryptographic algorithm, optionally compresses
it (or, for data received, decompresses it),
applies a MAC or HMAC and then encrypts (or
decrypts) the data using the information
negotiated during the Handshake Protocol.
Record Layer
Trong mô tả của RFC 2246 thì Record Layer có 4
chức năng sau:
• It fragments the data coming from the application into
manageable blocks (and reassemble incoming data to pass
up to the application).
• It compresses the data and decompresses incoming data.
• It applies a Message Authentication Code (MAC), or
hash/digest, to the data and uses the MAC to verify
incoming data.
• It encrypts the hashed data and decrypts incoming data.
Cách SSL/TLS làm việc
1. The first step in the process is for the client
to send the server a Client Hello message.
This hello message contains the SSL
version and the cipher suites the client can
talk. The client sends its maximum key
length details at this time.
2. The server returns the hello message with
one of its own in which it nominates the
version of SSL and the ciphers and key
lengths to be used in the conversation,
chosen from the choice offered in the client
hello.
3. The server sends its digital certificate to the
client for inspection. Most modern
browsers automatically check the
certificate (depending on configuration)
and warn the user if it's not valid. By valid
we mean if it does not point to a
certification authority that is explicitly
trusted or is out of date, etc.
4. The server sends a server done message
noting it has concluded the initial part of
the setup sequence.
Cách SSL/TLS làm việc
5. The client generates a symmetric key
and encrypts it using the server's public
key (cert). It then sends this message to
the server.
6. The client sends a cipher spec message
telling the server all future
communication should be with the new
key.
7. The client now sends a Finished message
using the new key to determine if the
server is able to decrypt the message and
the negotiation was successful.
8. The server sends a Change Cipher Spec
message telling the client that all future
communications will be encrypted.
9. The server sends its own Finished
message encrypted using the key. If the
client can read this message then the
negotiation is successfully completed.
Mô tả SSL/TLS làm việc
SSL Negotiation with Server Only Authentication
1. The first step in the process is for the client to send the server a Client Hello message. This hello
message contains the SSL version and the cipher suites the client can talk. The client sends its
maximum key length details at this time.
2. The server returns the hello message with one of its own in which it nominates the version of SSL
and the ciphers and key lengths to be used in the conversation, chosen from the choice offered in
the client hello.
3. The server sends its digital certificate to the client for inspection. Most modern browsers
automatically check the certificate (depending on configuration) and warn the user if it's not valid.
By valid we mean if it does not point to a certification authority that is explicitly trusted or is out
of date, etc.
4. The server sends a server done message noting it has concluded the initial part of the setup
sequence.
5. The client generates a symmetric key and encrypts it using the server's public key (cert). It then
sends this message to the server.
6. The client sends a cipher spec message telling the server all future communication should be with
the new key.
7. The client now sends a Finished message using the new key to determine if the server is able to
decrypt the message and the negotiation was successful.
8. The server sends a Change Cipher Spec message telling the client that all future communications
will be encrypted.
9. The server sends its own Finished message encrypted using the key. If the client can read this
message then the negotiation is successfully completed.
SSL with both Client and Server
Authentication
Thêm các bước :
4. The server sends a Certificate
request after sending its own
certificate.
6. The client provides its
Certificate.
8. The client sends a Certificate
verify message in which it
encrypts a known piece of
plaintext using its private key.
The server uses the client
certificate to decrypt, therefore
ascertaining the client has the
private key.
 Tìm hiểu SSL/TLS

Phần 3 Tấn công và cách phòng chống

Mô tả quá trình truyền thông HTTPS
 Connect Gmail
o Trình duyệt máy khách kết nối đến Gmail trên cổng 80 bằng cách sử
dụng HTTP.
o Máy chủ redirect phiên bản HTTPS máy khách của site này bằng
cách sử dụng HTTP code 302.
o Máy khách kết nối đến Gmail trên cổng 443.

o Máy chủ sẽ cung cấp một chứng chỉ cho máy khách gồm có chữ ký số
của nó. Chứng chỉ này được sử dụng để thẩm định sự nhận dạng của
site.
o Máy khách sử dụng chứng chỉ này và thẩm định chứng chỉ này với
danh sách các nhà thẩm định chứng chỉ tin cậy của nó.
o Truyền thông mã hóa sẽ xảy ra sau đó.
 Quá trình Attack
 Moxie Marlinspike, một chuyên gia nghiên cứu
bảo mật hàng đầu đã cho rằng trong hầu hết các
trường hợp, SSL chưa bao giờ bị trực tiếp tấn
công. Hầu hết thời gian một kết nối SSL được
khởi tạo thông qua HTTPS.
Ý tưởng:
 Nếu bạn tấn công một phiên giao dịch từ một kết nối không an
toàn đến một kết nối an toàn, trong trường hợp này là từ HTTP
vào HTTPS, bạn sẽ tấn công cầu nối và có thể “Man-in-the-
middle” kết nối SSL trước khi nó xuất hiện.
 Để thực hiện hiệu quả điều này, Moxie đã tạo một công cụ
SSLstrip, chúng ta sẽ sử dụng công cụ này dưới đây.
Chiếm quyền điều khiển truyền thông HTTPS
 Lưu lượng giữa máy khách và máy chủ đầu tiên sẽ bị chặn
 Khi bắt gặp một HTTPS URL, sslstrip sẽ thay thế nó bằng một
liên kết HTTP và sẽ ánh xạ những thay đổi của nó.
 Máy tấn công sẽ cung cấp các chứng chỉ cho máy chủ web và
giả mạo máy khách.
 Lưu lượng được nhận trở lại từ website an toàn và được cung
cấp trở lại cho máy khách.
 Quá trình làm việc khá tốt, máy chủ có liên quan vẫn nhận lưu
lượng SSL mà không hề biết về sự khác biệt này. Chỉ có một sự
khác biệt rõ rệt trong trải nghiệm người dùng là lưu lượng sẽ
không được cắm cờ HTTPS trong trình duyệt, vì vậy một người
dùng có kinh nghiệm sẽ có thể thấy đó là một điều dị thường.
 Review quá trình Attack sử dụng SSL-Trip

 Trước tiên, phân phối Linux mà bạn đang sử dụng phải được cấu
hình để chuyển tiếp IP. Để thực hiện điều này, hãy nhập lệnh echo
"1" > /proc/sys/net/ipv4/ip_forward vào một shell.
Khi thực hiện xong, chúng ta phải làm cho tất cả lưu lượng
HTTP được chặn sẽ được định tuyến đến cổng mà ở đó
SSLstrip sẽ lắng nghe. Điều này được thực hiện bằng cách
thay đổi cấu hình iptables của tường lửa. Sử dụng lệnh
iptables -t nat -A PREROUTING -p tcp --destination-port 80
-j REDIRECT --to-port <listenPort>.
 Thay thế <listenPort> bằng một cổng nào đó theo lựa
chọn của mình. Sau khi thực hiện xong việc cấu hình này,
chúng ta có thể chạy sslstrip và cấu hình sao cho nó có thể
lắng nghe trên cổng được chỉ định bằng lệnh sslstrip -l
<listenPort>.
Bước cuối cùng trong quá trình này là cấu hình giả
mạo ARP để chặn lưu lượng của host đích.Chúng ta
sẽ sử dụng tiện ích arpspoof có trong Backtrack 4.
Lệnh để thực hiện là arpspoof -i <interface> -t
<targetIP> <gatewayIP>.
 Biện pháp phòng chống
 Sử dụng kết nối an toàn HTTPS
 Khi bạn thực hiện tấn công được mô tả ở đây, nó sẽ lấy
đi khía cạnh an toàn của kết nối, thứ có thể xác định được
trong trình duyệt.
 Điều này có nghĩa rằng nếu bạn đăng nhập vào tài khoản
ngân hàng trực tuyến và thấy rằng nó chỉ là một kết nối
HTTP chuẩn thì chắc chắn có thứ gì đó sai ở đây.
 Bất cứ khi nào trình duyệt mà bạn chọn sử dụng cũng
cần bảo đảm rằng bạn biết cách phân biệt các kết nối an
toàn với những kết nối không an toàn
 Lưu tài khoản ngân hàng trực tuyến ở nhà
 Cơ hội cho ai đó có thể chặn lưu lượng của bạn trên
mạng gia đình sẽ ít hơn nhiều so với mạng ở nơi làm việc
của bạn.
 Điều này không phải vì máy tính gia đình của bạn an toàn
hơn (mà sự thật có lẽ là kém an toàn hơn), nhưng sự thật
nếu chỉ có một hoặc hai máy tính ở nhà thì các bạn chỉ
phải quan tâm đến việc chiếm quyền điều khiển session
nếu có ai đó trong nhà bạn bắt đầu xem và tập theo các
video về hacking trên YouTube.
 Trong mạng công ty, bạn không biết những gì
đang diễn ra dưới tiền sảnh hoặc văn phòng chi
nhánh cách đó nhiều km, vì vậy nguồn tấn công
tiềm tàng là rất nhiều.
 Một trong những mục tiêu lớn nhất cho tấn công
chiếm quyền điều khiển session là ngân hàng trực
tuyến, tuy nhiên thủ phạm này có thể áp dụng cho
bất cứ ai và cái gì.
 Bảo mật các máy tính bên trong mạng
 Các tấn công thường được thực thi bên trong một
mạng. Nếu các thiết bị mạng của bạn được an toàn
thì nguy cơ bị thỏa hiệp các host để sau đó được sử
dụng để khởi chạy tấn công chiếm quyền điều
khiển session cũng sẽ giảm.