Định nghĩa SSL
SSL là giao thức đa mục đích được thiết kế để mã hoá dữ liệu truyền giữa client và server.
Ví dụ: http + SSL = https (443), smtp + SSL = smtps (465), ftp + SSL = ftps (990), telnet + SSL
= telnets (992), SSL VPN = web VPN.
Các thuật toán mã hóa thông dụng được ssl sử dụng: DES, 3-DES, DSA và KEA (chính phủ Mỹ sử
dụng), MD5, RSA, SHA-1.
SSL nằm trong tầng ứng dụng của TCP/IP. SSL có thể được dùng trong hầu hết mọi hệ điều hành
hỗ trợ TCP/IP mà không cần phải chỉnh sửa kernel hay power shell của hệ thống (khác với IP Sec).
Giao thức SSL đã được phát triển liên tục kể từ khi được phát hành vào năm 1994. Các phiên bản
SSL 2.0 và SSL 3.0 do công ty Netscape phát hành đã được sử dụng rộng rãi. Sau đó, một tổ chức
tiêu chuẩn hóa Internet đã phát hành giao thức TLS 1.0 (còn được gọi là SSL 3.1) dựa trên SSL
3.0 và sau đó cũng phát hành phiên bản TLS1.1 và TLS 1.2. Hiện tại, hầu hết các trình duyệt chính
hiện nay đều hỗ trợ TLS 1.2.
Định nghĩa SSL VPN
SSL VPN được sử dụng để cho phép người dùng truy cập an toàn và hiệu quả vào tài nguyên mạng
nội bộ của doanh nghiệp từ bên ngoài doanh nghiệp.
SSL VPN được định nghĩa như là công nghệ truy cập từ xa dựa trên SSL. SSL VPN cho phép người
dùng từ bất kỳ vị trí nào có Internet dùng trình duyệt web (hay phần mềm VPN client) để thiết lập
kết nối an toàn về doanh nghiệp từ xa.
Như trong hình bên dưới FW đóng vai trò là gateway của doanh nghiệp và được kết nối với Internet.
FW cung cấp dịch vụ truy cập SSL VPN cho người dùng từ xa. Người dùng từ xa có thể sử dụng
các thiết bị di động (laptop, pad, smart phone) để truy cập tài nguyên mạng nội bộ thông qua FW
bất kỳ lúc nào và bất kỳ nơi nào.
Các tính năng cơ bản của SSL VPN
SSL VPN có lợi thế hơn các công nghệ VPN trong tình huống truy cập từ xa với có các tính năng
sau:
1
- Các thiết bị của người dùng từ xa có thể sử dụng trình duyệt web để truy cập tài nguyên mạng
nội bộ một cách an toàn và hiệu quả mà không cần bất kỳ phần mềm client bổ sung nào.
- Cho phép quản trị viên đặt quyền kiểm soát chi tiết đối với quyền của người dùng từ xa dựa trên
các loại tài nguyên được truy cập.
- Cung cấp nhiều chế độ xác thực: chẳng hạn như local authentication, server authentication,
certificate-anonymous authentication và certificate-challenge authentication.
- Hỗ trợ các chính sách kiểm tra host để kiểm tra xem hệ điều hành, port, các tiến trình và antivirus
software của thiết bị người dùng từ xa có đáp ứng các yêu cầu bảo mật hay không. Đồng thời cung
cấp các chứng năng chống an-tinested và anti-snapshot để loại bỏ rủi ro bảo mật từ thiết bị người
dùng từ xa.
- Hỗ trợ các chính sách xóa cache để xóa lịch sử truy cập mà người dùng từ xa để lại trong quá
trình truy cập tài nguyên mạng nội bộ, tăng cường bảo mật thông tin người dùng.
Cơ chế cơ bản của SSL VPN
Các bước thông thường (xem lại hình ngay trên) khi thực hiện dùng SSL VPN để truy cập về tài
nguyên của doanh nghiệp:
Bước 1: Mở trình duyệt, nhập địa chỉ VPN gateway: https://SSL VPN server address: port hoặc
https://domain để bắt đầu kết nối.
Bước 2: Trang web có thể đưa ra lời nhắc rằng có vấn đề với chứng chỉ bảo mật cho trang web
sắp được truy cập, thường thì sẽ chọn "tiếp tục đến trang web này".
Bước 3: Giao diện đăng nhập server SSL thành công xuất hiện. Lúc này sẽ yêu cầu nhập username
và password.
Bước 4: Nhập username và password (được cung cấp trước đó từ quản trị viên mạng doanh
nghiệp). Đăng nhập thành công vào server SSL VPN và truy cập vào trang truy cập tài nguyên
mạng nội bộ.
Đặt ra các câu hỏi sau:
Câu 1. Vài bước này có thể đảm bảo thiết lập kết nối SSL VPN và truy cập an toàn không?
Câu 2. Tại sao có lời nhắc rằng có vấn đề với chứng chỉ bảo mật của địa chỉ web được truy cập?
2 câu hỏi này được trả lời bằng các ý chính sau:
- Giao thức SSL bắt đầu hoạt động từ khi người dùng mở trình duyệt của mình và truy cập vào địa
chỉ server SSL VPN
- Người dùng từ xa trao đổi gói tin với server SSL VPN.
- Theo cơ bản trên thì phải có gói tin giúp người dùng từ xa gửi username và password. Đây thực
sự là server SSL VPN yêu cầu xác thực danh tính của người dùng (local authentication, server
authentication, certificate-anonymous authentication và certificate-challenge authentication).
- SSL là một giao thức bảo mật dựa trên ứng dụng Web do công ty Netscape phát triển, tất cả dữ
liệu được truyền đi đều được mã hóa, đảm bảo tính toàn vẹn dữ liệu.
2
Cơ chế hoạt động của SSL VPN
SSL record header
Vì SSL là giao thức client server nên điểm nhấn chính phải nói đến các gói tin trao đổi giữa client
và SSL VPN server.
Bên trong mỗi gói tin SSL là phần Record header chịu trách nhiệm đóng gói các message sẽ truyền
đi. SSL thiết lập kết nối giữa client và server bằng cách trao đổi các message được đóng gói trong
phần Record. Hình dưới đây là định dạng của phần Record trong gói tin SSL:
- Content Type: Cho biết loại message được đóng gói bên trong record này. Có 4 loại message:
+ Handshake: code 22
+ ChangeCipherSpec: code 20
+ Application: code 23
+ Alert: code 21
- Version: Cho biết version của giao thức, ví dụ SSL 2.0: Major 2, Minor 0; SSL 3.0: Major 3,
Minor 0; TLS 1.0: Major 3, Minor 1.
- Length: Chiều dài của record này.
- Encapsulated Protocol Message: Phần message hoặc application data được trao đổi giữa client
và server trong phiên làm việc. Sau khi các tham số liên quan đến encryption và hash được thương
lượng xong thì trường này sẽ được mã hóa.
- MAC: Giá trị MAC (Message Authentication Code) được tính toán cho phần application data chứa
trong encapsulated protocol message để đảm bảo tính toàn vẹn.
- Padding: Chèn thêm vào phần encapsulated protocol message cho đủ kích thước của một block.
Trường này không cần khi dùng kiểu mã hóa dòng (stream cipher).
3
SSL Protocol
Từ các Content Type sẽ hình thành SSL protocol. SSL protocol (SSL thuộc tầng Application trong
TCP/IP) bao gồm 2 layer:
Layer cao hơn có SSL handshake protocol, SSL change cipher spec protocol (SSL password change
protocol) và SSL alert protocol. Các protocol này được dùng trong quá trình thiết lập kết nối,
thương lượng các thông số bảo mật. Riêng SSL alert protocol được sử dụng để gửi cảnh báo SSL.
Nếu trong quá trình liên lạc, một bên phát hiện ra bất kỳ điều gì bất thường, bên đó sẽ gửi thông
báo cảnh báo cho bên kia
Layer thấp hơn là SSL record protocol: chịu trách nhiệm nén các khối dữ liệu ở application, đảm
bảo tính toàn vẹn của dữ liệu và mã hóa dữ liệu bằng cách sử dụng khóa được thương lượng bởi
handshake protocol.
SSL VPN phase
Từ SSL protocol hình thành cơ chế hoạt động cho SSL VPN. SSL VPN chia thành 2 phase: 1 và 2.
Phase 1 dùng các SSL protocol layer cao. Phase 2 dùng SSL protocol layer thấp.
SSL VPN phase 1 - SSL handshake
Phase này chính là thiết lập kết nối SSL chủ yếu dựa vào SSL handshake protocol.
Phương pháp thiết kế cơ bản của SSL handshake protocol có thể được tóm tắt như sau: truyền
bản mã bằng cách sử dụng một thuật toán mã hóa khóa công khai (mã hóa bất đối xứng). Hay
nói cách khác, server thông báo khóa công khai của mình cho client, sau đó client sử dụng khóa
công khai của server để mã hóa thông tin và sau khi server nhận được bản mã, nó sẽ sử dụng
khóa riêng của chính nó để giải mã.
Thuật toán mã hóa khóa công khai còn được gọi là thuật toán mã hóa bất đối xứng:
- Client A muốn gửi thông tin cho Server B. Server B cần tạo 1 public key và private key để dùng
cho việc mã hóa và giải mãi.
- Server B giữ private key bí mật và gửi public key cho Client A.
4
- Khi Client A muốn gửi thông tin cho Server B, Client A dùng public key của Server B để mã hóa
thông tin (vì client A biết pubic key của Server B).
- Server B nhận được thông tin, Server B sẽ dùng private key để giải mã. Bất cứ ai nhận được
thông tin cũng sẽ không có private key để giải mã. Vì private key chỉ Server B biết.
- Khi Server B muốn gửi thông tin cho Client A thì sẽ dùng public key của Client A. Và client A
cũng sẽ giữ Private key cho riêng nó.
Có hai vấn đề với cách tiếp cận thiết kế này đòi hỏi các giải pháp tinh chỉnh hơn:
1. Khi server thông báo public key của nó cho client, làm thế nào nó có thể đảm bảo rằng public
key không bị giả mạo?
Giải pháp: kết hợp digital certificate. Input public key của server vào server certificate, server sẽ
gửi certificate đến client. Miễn là certificate đáng tin cậy, thì public key có thể được tin cậy.
2. Tính bảo mật của thuật toán mã hóa khóa công khai là cao, vì hai thiết bị đầu cuối đều sử dụng
khóa riêng để giải mã, thuật toán tương đối phức tạp - làm thế nào để tăng hiệu quả?
Giải pháp: kết hợp với một session key. Client và server thương lượng session key bằng thuật toán
mã hóa khóa công khai và các gói dữ liệu tiếp theo đều sử dụng session key này để mã hóa và
giải mã (đây còn được gọi là thuật toán mã hóa đối xứng). Tốc độ tính toán rất nhanh khi sử dụng
thuật toán mã hóa đối xứng, cho phép tăng hiệu quả tính toán của mã hóa và giải mã.
Session key thực sự là một khóa bí mật được chia sẻ bởi server và client. Nó được gọi là Session
key vì nó kết hợp khái niệm Session (phiên làm việc SSL VPN giữa client và server). Mọi kết nối
SSL dựa trên TCP được liên kết với một Session và Session được tạo bởi SSL handshake protocol.
SSL handshake protocol bao gồm 4 bước giao tiếp giữa server và client, do đó đảm bảo truyền gói
tin được mã hóa an toàn và hiệu quả cao có thể được tiến hành sau giai đoạn bắt tay, tức là ở
phase 2. Hình bên dưới là 4 bước này:
5
Bước 1: Client gửi request gói Client Hello (1, 0x01)
Client (thường là trình duyệt) trước tiên gửi một request được mã hóa đến server với mục đích là
client muốn thiết lập kết nối an toàn với server. Thông tin chính được cung cấp cho server trong
bước này như sau:
(1) Version giao thức được hỗ trợ, ví dụ: phiên bản TLS 1.0.
(2) Các thông số bảo mật (bộ mật mã - cipher suite) mà client có hỗ trợ.
(3) Một số ngẫu nhiên được tạo bởi client, góp phần trong tạo session key.
Bước 2: Server gửi response cho client bằng gói Server Hello (2, 0x02)
Sau khi nhận được client request, server sẽ gửi response đến client bằng server hello với mục đích
là server đồng ý khởi tạo kết nối. Bước này bao gồm các thông tin sau:
(1) Xác nhận version của giao thức SSL đang được sử dụng, ví dụ: phiên bản TLS 1.0. Nếu phiên
bản được hỗ trợ bởi trình duyệt và server không giống nhau, thì máy chủ sẽ đóng giao tiếp.
(2) Một số ngẫu nhiên do server tạo, góp phần trong tạo session key.
(3) Xác nhận bộ mật mã - cipher suite mà cả client và server cùng hỗ trợ và đảm bảo là mạnh và
mới nhất
(4) Server certificate (11, 0x0B) để cho client xác thực server.
(5) Server Key Exhange (12, 0x0C) dùng để gửi public key của server cho client. Chú ý là public
key của server được nằm trong Server certificate.
(6) Client Certificate Request (13, 0x0D). Do SSL handshake protocol hỗ trợ xác thực hai chiều
giữa client và server nên Client Certificate Request được server dùng để yêu cầu client gửi thông
tin xác thực đến server.
(7) ServerHelloDone (14, 0x0E): Đây là gói cuối cùng trong Bước 2, server gửi đến client để
cho biết tất cả thông tin của server đều đã được gửi hết.
Sau khi các gói tin ClientHello và ServerHello được trao đổi thì client và server đã thương lượng
xong các thuật toán encryption, hash và authentication sẽ sử dụng.
Bước 3: Client Response
Sau khi client nhận được response của server ở Bước 2, trước tiên client sẽ xác thực server
certificate. Nếu certificate không được cấp bởi một tổ chức đáng tin cậy hoặc nếu certificate domain
name và real domain name không giống nhau hoặc nếu certificate đã hết hạn, thì client sẽ hiển
thị một cảnh báo bằng cách dùng SSL alert protocol, trong đó có thể đưa ra lựa chọn có tiếp tục
giao tiếp hay không. Nếu không có vấn đề gì với certificate, client sẽ trích xuất public key của
server từ certificate.
Sau đó, client sẽ gửi các mục thông tin sau đến server:
(1) Client Certificate. Tương ứng với gói số (6) trong bước 2 thì client sẽ gửi identity certificate
của nó cho server. Chú ý là trong certificate này có chứa public key của client.
6
(2) ClientKeyExchange(16, 0x10): Trong ClientKeyExchange có chứa pre_master secret. Premaster key này được client tạo từ số ngẫu nhiên, được mã hóa bằng public key của server. khi
server nhận được sẽ giải mã bằng private key tương ứng. Bây giờ cả client và server sẽ sử dụng
pre_master secret cùng với 2 con số ngẫu nhiên đã phát sinh trước đó để tạo ra master key và
sau đó từ master key sẽ tạo ra session key dùng để mã hóa dữ liệu được truyền trong Session
đang được thực hiện kết nối.
(3) Certificate verify (15, 0x0F): Gói tin này chứa chuỗi hash được tính cho tất cả các message
đã trao đổi giữa client và server cho đến lúc này và được mã hóa bằng private key của client. Bên
Server sẽ sử dụng public key tương ứng (chứa trong certificate của client) để giải mã gói tin. Việc
giải mã thành công sẽ giúp server chứng thực được client.
(4) ChangeCipherSpec được dùng bởi SSL change cipher spec protocol, ChangeCipherSpec
được gửi cho server để cho biết kể từ lúc này, tất cả các gói tin trao đổi giữa client và server đều
sẽ được mã hóa bằng các thuật toán và key đã thương lượng trước đó.
(5) ClientFinishMessage: Client gửi đến server để cho biết client đã hoàn tất việc thiết lập tunnel.
Giai đoạn handshake của client đã được kết thúc.
Bước 4: Server response lần 2
Sau khi server nhận được pre-master key của client, nó sẽ tính toán và tạo session key để sử dụng
cho session này (phương pháp tính toán và kết quả được tính giống như của client). Dưới đây,
thông tin cuối cùng được gửi đến client:
(1) ChangeCipherSpec, tương tự như phía client thì server dùng gói này để thể hiện rằng tất cả
thông tin trong tương lai sẽ được gửi bằng phương pháp mã hóa và key đã thương lượng trước đó.
(2) ServerFinishMessage: server gửi đến client để cho biết server đã hoàn tất việc thiết lập
tunnel. Giai đoạn handshake của server đã được kết thúc.
Phía trên là nội dung cụ thể của 4 Bước của SSL handshake protocol, có một số câu hỏi như sau:
(1) Khi pre-master key xuất hiện, client và server đã có 2 số ngẫu nhiên và sau đó 2 số này sử
dụng phương pháp mã hóa đã thương lượng trước đó để tạo ra cùng một session key được sử dụng
trong session. Tại sao cần 2 số ngẫu nhiên để tạo session key?
Trả lời: Rõ ràng là thuật toán mã hóa khóa công khai sử dụng 2 số ngẫu nhiên để lấy secret key
đối xứng cuối cùng được thực hiện nhằm tăng tính bảo mật. Lý do pre-master key tồn tại là do
giao thức SSL không tin tưởng rằng mọi server lưu trữ sẽ có thể tạo các số ngẫu nhiên là "hoàn
toàn ngẫu nhiên". Nếu các số ngẫu nhiên không phải là ngẫu nhiên, thì có thể suy ra chúng, tạo
ra các vấn đề về bảo mật.
(2) Trong Bước 2 của SSL handshake protocol, khi server respond (server hello), server sẽ gửi
certificate của chính nó và client ngay lập tức tiến hành xác minh certificate của server; điều này
có nghĩa là client xác minh tính hợp pháp của server. Điều này có liên quan đến cảnh báo gặp phải
khi đăng nhập vào máy chủ SSL VPN rằng "có vấn đề với chứng chỉ bảo mật của trang web này"
không?
Trả lời: Trên thực tế, SSL protocol bắt đầu hoạt động từ khi client (remote user) truy cập vào SSL
VPN server thông qua HTTPS. Thông báo trên chỉ xảy ra tương ứng với Bước 2 của SSL handshake
7
protocol ― tại thời điểm này server gửi certificate của chính nó cho client và client cần tiến hành
xác thực chứng chỉ của server. Sự xuất hiện của cảnh báo cho rằng chứng chỉ của máy chủ này
không đáng tin cậy. Nhưng nếu lời nhắc này xuất hiện trong quá trình truy cập hàng ngày của
chúng tôi vào ngân hàng trực tuyến và các giao diện tương tự khác, cần nâng cao cảnh giác để
tránh nhập nhầm các trang web lừa đảo.
Xét 1 tình huống thực tế như sau:
Bước 1. Sử dụng FW làm SSL VPN server.
Bước 2. Client tiến hành đăng nhập vào thông qua SSL VPN.
a. client 10.108.84.93 bắt đầu yêu cầu kết nối bằng trình duyệt IE tới gateway FW bằng
https://10.174.64.61. Trong hình bên dưới, các số 21-29 hiển thị toàn bộ quy trình SSL handshake
4 giao tiếp. Sau khi server trả lời Server Finished Message (đã được mã hóa; có một lưu ý rằng
đây là thông báo bắt tay được mã hóa) ở số 29, alert interface cho biết chứng chỉ bảo mật có vấn
đề sẽ xuất hiện. Tại thời điểm này, client và server thực sự chưa bắt đầu giao tiếp bình thường mà
đang trong giai đoạn SSL handshake. Client đã xác minh rằng server không hợp pháp và giao diện
Web của client đã hỏi người dùng xem họ có muốn tiếp tục duyệt trang web này hay không.
b. Để ủy thác sự tin tưởng, hãy chọn "tiếp tục đến trang web này". Bắt đầu từ số 103, ứng dụng
client yêu cầu sử dụng một phiên mới và lại bắt đầu giao thức SSL handshake. Sau khi hoàn thành
handshake, giao tiếp được mã hóa thông thường sẽ bắt đầu và tiếp tục cho đến khi trình duyệt
của người dùng tải thành công giao diện đăng nhập người dùng của gateway FW.
8
c. Username và password được nhập. Bắt đầu từ số 1561, việc khởi tạo SSL handshake được tiếp
tục. Sau 4 giao tiếp, session key được thương lượng và tất cả dữ liệu giữa client và server được
mã hóa ("Application Data") và được gửi đến server.
Định nghĩa các phương pháp xác thực
9
Để đảm bảo tính hợp pháp của SSL VPN remote user và để cải thiện bảo mật hệ thống, SSL VPN
server thường hỗ trợ nhiều phương pháp xác thực. Ở trên, là sử dụng cấu hình và lưu trữ tên
username/password trên FW làm ví dụ. Đây là phương thức xác thực cơ bản và đơn giản nhất. Các
phương thức xác thực có thể được hỗ trợ:
- Local authentication cho user name/password: đề cập đến việc cấu hình và lưu trữ
username/password trên SSL VPN server. Người dùng có thể đăng nhập thành công bằng cách
nhập username/password phù hợp.
- Server authentication cho user name/password: đề cập đến việc lưu trữ username/password
trên một máy chủ xác thực bên thứ ba đặc biệt. Sau khi người dùng nhập username/password,
SSL VPN server sẽ chuyển tiếp thông tin này đến máy chủ xác thực để xác thực. Các loại máy chủ
xác thực được hỗ trợ hiện nay bao gồm RADIUS, HWTACACS, SecurID, AD và LDAP.
- Anonymous certificate authentication: đề cập đến user's client cấu hình client certificate. SSL
VPN server xác minh certificate của client để xác thực danh tính của người dùng.
- Challenge certificate authentication: đề cập đến server sử dụng xác thực hai yếu tố (user
name/password+ client certificate) để xác thực danh tính của người dùng. Loại phương pháp này
rõ ràng là an toàn nhất.
10