tìm hiểu ssl – mô phỏng ssl bằng https

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.17 MB, 36 trang )

1
Lời Mở Đầu
Ngày nay với sự bùng nổ công nghệ thông tin, các hoạt động của con người
trên môi trường mạng internet đã trở nên vô cùng phổ biến, các công cụ ngày càng
phát triển giúp con người tương tác thân thiện hơn với môi trường mạng. Đi kèm với
sự phát triển đó việc bảo mật thông tin trên môi trường mạng trở nên cấp thiết. Có rất
nhiều giải pháp bảo mật đang được sử dụng. Trong báo cáo này em xin đề cập đến
chứng thực SSL.
2
Chương 1: Tổng Quan SSL
1.1. Giới thiệu chung về SSL
SSL (Secure Sockets Layer) là giao thức đa mục đích được thiết kế để tạo ra
các giao tiếp giữa hai chương trình ứng dụng trên một cổng định trước (socket 443)
nhằm mã hoá toàn bộ thông tin đi/đến, được sử dụng trong giao dịch điện tử như
truyền số liệu thẻ tín dụng, mật khẩu, số bí mật cá nhân (PIN) trên Internet.
Trong các giao dịch điện tử trên mạng và trong các giao dịch thanh toán trực
tuyến, thông tin/dữ liệu trên môi trường mạng Internet không an toàn thường được bảo
đảm bởi cơ chế bảo mật thực hiện trên tầng vận tải có tên Lớp cổng bảo mật SSL
(Secure Socket Layer) – một giải pháp kỹ thuật hiện nay được sử dụng khá phổ biến
trong các hệ điều hành mạng máy tính trên Internet.
Chúng ta thường gặp hầu hết giao thức ống ảo ở tầng transport, xa hơn nữa, là
giao thức Secure Sockets Layer (SSL) nằm trong những thứ khác, bảo mật những tác
vụ HTML (Hypertext Markup Language) trên Web. Khi chúng ta gặp, SSL có rất
nhiều những ứng dụng và có thể dễ dàng được sử dụng để xây dựng mục đích tổng
quát những đường ống ảo ở tầng Transport. SSL hoạt động trên vùng rộng nghĩa là
những tiện ích của TCPdump và SSLdump, hãy xem cách thức chúng ta có thể sử
dụng để xây dựng một đường ống ảo giữa hai chương trình hoặc cả hai cái không cần
đến những quan tâm đến SSL, cuối cùng hãy xem cách chúng ta có thể sử dụng SSL
để xây dựng một VPN giữa hai mạng.
3
4

1.2. Tổng quan về SSL
SSL là một sự xuất hiện bổ sung của VPN trên thị trường. Nó được thiết kế cho
những giải pháp truy cập từ xa và không cung cấp những kết nối site-to-site. SSL
VPNs cung cấp vấn đề bảo mật truy cập đầu tiên những ứng dụng web. Bởi vì SSL sử
dụng trình duyệt web, điển hình là những người sử dụng không phải chạy bất kỳ phần
mềm client đặc biệt nào trên những máy tính của họ.
SSL VPNs hoạt động ở tầng phiên (session layer) của mô hình tiêu chuẩn OSI.
Và bởi vì client là một trình duyệt web, chỉ những ứng dụng đó mà chúng hổ trợ trình
duyệt web, bằng mặc định, nó sẽ làm việc với một giải pháp VPN. Vì thế những ứng
dụng như Telnet, FTP, SMTP, POP3, multimedia, hệ thống điện thoại di động IP, điều
khiển desktop từ xa, và những cái khác không làm việc với SSL VPNs bởi vì chúng
không sử dụng trình duyệt web cho giao diện đầu cuối người dùng của họ. Tất nhiên,
5
nhiều nhà cung cấp cũng sử dụng cả java hoặc ActiveX để nâng cao SSL VPNs bằng
việc hổ trợ những ứng dụng không phải là HTTP, những khách hàng là POP3, SMTP
e-mail, và tập tin Microsoft Windows và chia sẻ máy in. Ví dụ sự bổ sung SSL VPNs
của Cisco hỗ trợ những ứng dụng không phải là web chẳng hạn Citrix, Windows
Terminal Services, và nhiều cái khác. Thêm vào đó, một vài nhà cung cấp sử dụng
java hay ActiveX để phân phối những thành phần SSL VPNs khác, chẳng hạn như
thêm vào những chức năng bảo mật cho việc xóa hết những dấu vết từ một hoạt động
của một khách hàng trên máy tính của họ sau khi SSL VPNs đã được kết thúc. Cisco
chỉ sự bổ xung SSL VPN như là WebVPN.
1.3. Hoạt động của SSL
Điểm cơ bản của SSL là được thiết kế độc lập với tầng ứng dụng để đảm bảo
tính bí mật, an toàn và chống giả mạo luồng thông tin qua Internet giữa hai ứng dụng
bất kỳ, thí dụ như webserver và các trình duyệt (browser), do đó được sử dụng rộng rãi
trong nhiều ứng dụng khác nhau trên môi trường Internet. Toàn bộ cơ chế hoạt động
và hệ thống thuật toán mã hoá sử dụng trong SSL được phổ biến công khai, trừ khoá
chia sẻ tạm thời được sinh ra tại thời điểm trao đổi giữa hai ứng dụng là tạo ngẫu nhiên
và bí mật đối với người quan sát trên mạng máy tính. Ngoài ra, giao thức SSL còn đòi

hỏi ứng dụng chủ phải được chứng thực bởi một đối tượng lớp thứ ba (CA) thông qua
chứng chỉ điện tử (digital certificate) dựa trên mật mã công khai (thí dụ RSA). Sau đây
ta xem xét một cách khái quát cơ chế hoạt động của SSL để phân tích cấp độ an toàn
của nó và các khả nǎng áp dụng trong các ứng dụng nhạy cảm, đặc biệt là các ứng
dụng về thương mại và thanh toán điện tử.
Giao thức SSL dựa trên hai nhóm con giao thức là giao thức “bắt tay”
(handshake protocol) và giao thức “bản ghi” (record protocol). Giao thức bắt tay xác
định các tham số giao dịch giữa hai đối tượng có nhu cầu trao đổi thông tin hoặc dữ
liệu, còn giao thức bản ghi xác định khuôn dạng cho tiến hành mã hoá và truyền tin hai
chiều giữa hai đối tượng đó. Khi hai ứng dụng máy tính, thí dụ giữa một trình duyệt
web và máy chủ web, làm việc với nhau, máy chủ và máy khách sẽ trao đổi “lời chào
(hello) dưới dạng các thông điệp cho nhau với xuất phát đầu tiên chủ động từ máy chủ,
6
đồng thời xác định các chuẩn về thuật toán mã hoá và nén số liệu có thể được áp dụng
giữa hai ứng dụng. Ngoài ra, các ứng dụng còn trao đổi “số nhận dạng/khoá theo
phiên” (session ID, session key) duy nhất cho lần làm việc đó. Sau đó ứng dụng khách
(trình duyệt) yêu cầu có chứng chỉ điện tử (digital certificate) xác thực của ứng dụng
chủ (web server).
Chứng chỉ điện tử thường được xác nhận rộng rãi bởi một cơ quan trung gian
(Thẩm quyền xác nhận CA – Certificate Authority) như RSA Data Sercurity hay
VeriSign Inc., một dạng tổ chức độc lập, trung lập và có uy tín. Các tổ chức này cung
cấp dịch vụ “xác nhận” số nhận dạng của một công ty và phát hành chứng chỉ duy nhất
cho công ty đó như là bằng chứng nhận dạng (identity) cho các giao dịch trên mạng, ở
đây là các máy chủ webserver.
Sau khi kiểm tra chứng chỉ điện tử của máy chủ (sử dụng thuật toán mật mã
công khai, như RSA tại trình máy trạm), ứng dụng máy trạm sử dụng các thông tin
trong chứng chỉ điện tử để mã hoá thông điệp gửi lại máy chủ mà chỉ có máy chủ đó
có thể giải mã. Trên cơ sở đó, hai ứng dụng trao đổi khoá chính (master key) – khoá bí
mật hay khoá đối xứng – để làm cơ sở cho việc mã hoá luồng thông tin/dữ liệu qua lại
giữa hai ứng dụng chủ khách. Toàn bộ cấp độ bảo mật và an toàn của thông tin/dữ liệu

phụ thuộc vào một số tham số:
• Số nhận dạng theo phiên làm việc ngẫu nhiên.
• Cấp độ bảo mật của các thuật toán bảo mật áp dụng cho SSL.
• Độ dài của khoá chính (key length) sử dụng cho lược đồ mã hoá thông tin.
1.4. Lịch sử phát triển SSL
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.
7
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:
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: đượ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.

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).
8
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.
1.4. Ứng dụng SSL trong thương mại điện tử
Trong thực tiễn, sự hiểu biết của người sử dụng về cơ chế bảo mật được “sắp
đặt” trong các giao dịch điện tử trên mạng Internet là ít ỏi và mờ. Tất cả phần lớn dựa
vào sự tin tưởng (trust), chẳng hạn tên tuổi của các hãng có uy tín (VisaCard,
MasterCard, ) và sản phẩm có tính nǎng tốt của các hãng nổi tiếng (Oracle,
Microsoft, Netscape, ). Bảo mật và an toàn là vấn đề quan trọng trong việc quyết định
sự phát triển mạnh mẽ thương mại điện tử hoặc hiện nay như chính phủ điện tử (e-
government) và tạo lòng tin cho khách hàng và công chúng. Qua phân tích ví dụ của
bảo mật trong giao thức SSL, cho ta thấy mặt khác của vấn đề: khả nǎng lựa chọn
công nghệ và mức độ phụ thuộc vào công nghệ, khi xây dựng các ứng dụng nền tảng
trong đó có hạ tầng bảo mật thông tin.
Việc triển khai các hệ thống ứng dụng sử dụng hạ tầng truyền thông Internet
đòi hỏi có độ bảo mật cao (đặc biệt trong ngân hàng, tài chính, quốc phòng ) cần phải
được xây dựng dựa trên sơ đồ gồm các lớp bảo mật nhiều tầng độc lập (thí dụ: giao
thức Giao dịch điện tử bảo mật SET (Secure Electronic Transaction), Giao thức khoá
Internet IKP (Internet Keyed Protocol) hoặc PGP (Pretty Good Privacy), thậm chí cả
phần cứng, nhằm hạn chế tối đa các “lỗ hổng” bảo mật của hệ thống giao thương điện

tử. Ngoài ra cũng cần lưu ý các sản phẩm về bảo mật ứng dụng hiện nay trên mạng
máy tính phần lớn được phát minh từ Mỹ, được bảo hộ và kiểm soát chặt chẽ bởi luật
pháp Mỹ dẫn đến khi thực hành xây dựng và triển khai các hệ thống thông tin và giao
dịch thương mại điện tử của chúng ta cần thận trọng và cân nhắc.
9
Chương 2: Cấu Trúc Và Các Giao Thức Bảo Mật
2.1. Cấu trú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.
Hình 1.1: Cấu trúc của SSL và giao thức SSL
10
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).
11
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).
12
Bảng 1.2: Các số cổng được gán cho các giao thức ứng dụng chạy trên
TLS/SSL.
Nói chung, một session SSL có trạng thái và giao thức SSL phải khởi tạo và
duy trì thông tin trạng thái ở một trong hai phía của session. Các phần tử thông tin
trạng thái session tương ứng bao gồm một session ID, một chứng nhận ngang hàng,
một phương pháp nén, một thông số mật mã, một khóa mật chính và một cờ vốn chỉ
định việc session có thể tiếp tục lại hay không, được tóm tắt trong bảng 1.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
13
Bảng 1.4 Các thành phần thông tin trạng thái nối kết SSL
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.
14
Sau khi SSL Handshake Protocol đã hoàn tất, dữ liệu ứng dụng có thể được gửi
và được nhận bằng cách sử dụng SSL Record Protocol và các tham số bảo mật được
thương lượng và các thành phần thông tin trạng thái.
2.2. Các Giao Thức Bảo Mật SSL
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.
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:
15
– 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.
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.
16
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.
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.
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
17
SSL vốn được xử lý và được chuyển như được xác định bởi phương pháp nén và thông
số mật mã của session SSL hiện hành và các khóa mật mã của nối kết SSL tương ứng.
Mục đích của SSL Handshake Protocol là yêu cầu một client và server thiết lập và duy
trì thông tin trạng thái vốn được sử dụng để bảo vệ các cuộc liên lạc. Cụ thể hơn, giao
thức phải yêu cầu client và server chấp thuận một phiên bản giao thức SSL chung,
chọn phương thức nén và thông số mật mã, tùy ý xác thực nhau và tạo một khóa mật
chính mà từ đó các khóa session khác nhau dành cho việc xác thực và mã hóa thông
báo có thể được dẫn xuất từ đó.
Tóm lại, việc thực thi SSL Handshake Protocol giữa một client C và một server
S có thể được tóm tắt như sau (các thông báo được đặt trong các dấu ngoặc vuông thì
tùy ý):
1: C -> S: CLIENTHELLO

2: S -> C: SERVERHELLO
[CERTIFICATE]
[SERVERKEYEXCHANGE]
[CERTIFICATEREQUEST]
SERVERHELLODONE
3: C -> [CERTIFICATE]
CLIENTKEYEXCHANGE
[CERTIFICATEVERIFY]
CHANGECIPHERSPEC
FINISHED
18
4: S -> C: CHANGECIPHERSPEC
FINISHED
Hình 1.6: Giao tiếp giữa server và clien
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).
19
– Một cấu trúc ngẫu nhiên do client tạo ra gồm một tem thời gian 32 bit có dạng
UNIX chuẩn và một giá trị 28 byte được tạo ra bởi một bộ tạo số giả ngẫu nhiên.
– Một định danh session mà client muốn sử dụng cho nối kết này.
– Một danh sách các bộ mật mã client hỗ trợ.
– Một danh sách các phương pháp nén mà client hỗ trợ.
Chú ý rằng trường session identity (định danh session) nên rỗng nếu session
SSL hiện không tồn tại hoặc nếu client muốn tạo các tham số bảo mật mới. Ở một
trong hai trường hợp, một trường session identity không rỗng là xác định một session

SSL hiện có giữa client và server (nghĩa là một session có các tham số bảo mật mà
client muốn sử dụng lại.). Định danh session có thể bắt nguồn từ một nối kết trước đó,
nối kết này hoặc một nối kết đang hoạt động. Cũng chú ý rằng danh sách các bộ mật
mã được hỗ trợ, được chuyển từ client đến server trong thông báo CLIENTHELLO,
chứa các tổ hợp thuật toán mật mã được hỗ trợ bởi client theo thứ tự ưu tiêm. Mỗi bộ
mật mã xác định một thuật toán trao đổi khóa và một thông báo mật mã. Server sẽ
chọn một bộ mật mã hoặc nếu các lựa chọn có thể chấp nhận được không được trình
bầy, trả về một thông báo lỗi và đóng nối kết một cách phù hợp. Sau khi đã gởi thông
báo CLIENTHELLO, client đợi một thông báo SERVERHELLO. Bất kỳ thông báo
khác được trả về bởi server ngoại trừ một thông báo HELLOREQUEST được xem như
là một lỗi vào thời điểm này.
Ở bước 2, server xử lý thông báo CLIENTHELLO và đáp ứng bằng một thông
báo lỗi hoặc thông báo SERVERHELLO. Tương tự như thông báo CLIENTHELLO,
thông báo SERVERHELLO có các trường sau đây:
– Một số phiên bản server chứa phiên bản thấp hơn của phiên bản được đề nghị
bởi client trong thông báo CLIENTHELLO và được hỗ trợ cao nhất bởi Server.
– Một cấu trúc ngẫu nhiên do server tạo ra cũng gồm một tem thời gian 32bit có
dạng UNIX chuẩn và một giá trị 28bit được tạo ra bởi một bộ tạo số ngẫu nhiên.
20
– 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 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
21
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 CERTIFICATE Request đế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 SERVERHELLO Done đến client
để chỉ định sự kết thúc SERVERHELLO và các thông báo đi kèm.
Sau khi nhận SERVERHELLO và các thông báo đi kèm, client xác nhận rằng
chứng nhận site server (nếu được cung cấp) là hợp lệ và kiểm tra nhằm bảo đảm rằng
các thông số bảo mật được cung cấp trong thông báo SERVERHELLO có thể được
chấp nhận. Nếu server yêu cầu sự xác thực client, client gởi một thông báo
CERTIFICATE vốn chứa một chứng nhận cá nhân cho khóa chung của người dùng
đến server ở bước 3. Tiếp theo, client gởi một thông báo 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ử
22
dụng khóa chung từ chứng nhận server cùng với một số tham số riêng trong token của
client. Client gởi các tham số chung cần thiết cho server để cũng tạo TEK, sử dụng các
tham sô riêng của nó. Nó tạo một khóa mật chính, bao bọc nó bằng cách sử dụng TEK
và gởi kết quả cùng với một số vector khởi tạo đến server như là một phần của thông
báo CLIENTKEYEXCHANGE. Lần lượt, server có thể giải mã khóa mật chính một
cách thích hợp. Thuật toán trao đổi khóa này không được sử dụng rộng rãi.
Nếu sự xác thực client được yêu cầu, client cũng gởi một thông báo
CERTIFICATEVERIFY đến server. Thông báo này được sử dụng để cung cấp sự xác
thực rõ ràng định danh của người dùng dựa vào chứng nhận các nhân. Nó chỉ được gởi
theo sau một chứng chỉ client vốn có khả năng tạo chữ ký (tất cả chứng nhận ngoại trừ
các chứng nhận chứa các tham số DiffeHallman cố định). Sau cùng, client hoàn tất
bước 3 bằng cách gởi một thông báo CHANGECIPHERSPEC và một thông báo
FINISHED tương ứng đến server. Thông báo FINISHED luôn được gởi ngay lập tức

sau thông báo CHANGECIPERSPEC để xác nhận rằng các tiến trình trao đổi khóa và
xác thực đã thành công. Thực tế, thông báo FINISHED là thông báo đầu tiên vốn được
bảo vệ bằng các thuật toán mới được thương lượng và các khóa session. Nó chỉ có thể
được tạo và được xác nhận nếu những khóa này được cài đặt một cách phù hợp ở cả
hai phía. Không đòi hỏi sự báo nhận thông báo FINISHED; các phía có thể bắt đầu gởi
dữ liệu được mã hóa ngay lập tức sau khi đã gởi thông báo FINISHED. Việc thực thi
SSL Handshake Protocol hoàn tất bằng việc cũng yêu cầu server gởi một thông báo
CHANGECIPHERSPEC và một thông báo FINISHED tương ứng đến client ở bước 4.
Sau khi sự thiết lập SSL hoàn tất, một nối kết an toàn được thiết lập giữa client
và server. Nối kết này bây giờ có thể được sử dụng để gởi dữ liệu ứng dụng vốn được
bao bọc bởi SSL Record Protocol. Chính xác hơn, dữ liệu ứng dụng có thể được phân
đoạn, được nén, hoặc được mã hóa và đước xác thực theo SSL Record Protocol cũng
như thông tin trạng thái session và nối kết vốn bây giờ được thiết lập (tùy thuộc việc
thực thi SSL Handshake Protocol).
SSL Handshake Protocol có thể được rút 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
23
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 dụng
Những bổ sung SSL Client (SSL Client Implementations)
Một nguyên nhân chính mà những người quản trị mạng yêu cầu đưa ra những
bổ sung SSL VPN những giao thức SSL VPNs mà không yêu cầu bất cứ loại phần
mềm đặc biệt của VPN Client nào để được cài đặt trước trên những máy tính để bàn
của người sử dụng. Tất nhiên, người sử dụng biết một vài phần mềm cần thiết, giống
như một trình duyệt web đươc hổ trợ SSL, đặc thù với cả Java và ActiveX cũng được
hổ trợ, và hầu như người sử dụng đã cài những điều này từ một sự cài đặt ban đầu trên
máy tính.
24
Có 3 loại SSL Client Implementation tổng quát:
• Clientless
• Thin client
• Network client
Bởi vì chỉ một trình duyệt web được yêu cầu trên máy tính người sử dụng, SSL
client thông thường được xem như là “Clientless” hoặc “webified”. Vì thế SSL VPN
thỉnh thoảng được gọi là clientless VPN. Điều trở ngại chính của một clientless VPN
là chỉ giao thông dạng web có thể được bảo vệ.
Đặc thù của một Thin client là phần mềm java hoặc ActiveX đã tải xuống thông
qua SSL VPN đến máy tính người sử dụng. Nó cho phép một tập hợp nhỏ những ứng
dụng không phải là web được vận chuyển thông qua SSL VPN. Trong việc truy cập
dựa vào mạng, một SSL client được cài đặt trên máy tính của người sử dụng; tuy
nhiên, đặc tính này được tải xuống máy tính của người sử dụng.
SSL Protection
SSL VPN không cần thiết cung cấp việc bảo vệ của dữ liệu ở tầng network,
chẳng hạn như IPSec, PPTP, và L2TP. Client SSL VPN cung cấp việc bảo vệ cho
những ứng dụng web ở tầng Session (tầng thứ 5) mà chúng sử dụng trình duyệt web.

Vì thế, nó sử dụng việc bảo vệ giao thông ở một vài thứ được giới hạn, cho ứng dụng
giao thông được bảo vệ, một vài cách sự truy cập của người sử dụng đến ứng dụng
phải thông qua một trình duyệt web. Tất nhiên, bất kỳ một cách kết nối kiểu HTTP có
thể dễ dàng được bảo vệ bởi vì người sử dụng sử dụng trình duyệt web cho kiểu chức
năng này, nhưng điều này có thể xuất hiện những vấn đề cho những kiểu ứng dụng
khác, chẳng hạn như Telnet, POP3, SMTP, SNMP, ping, traceroute, FTP, IP
telephony, Citrix, Oracle’s SQL*net, tập tin và việc chia sẽ máy in thông qua
Windows hoặc Unix và nhiều thứ khác.
25
Chương 3: Mô phỏng lấy certificate SSL trong HTTPS
3.1. Chuẩn bị
Mô hình mạng cần để thực hiện mô phỏng gồm có:
Một máy DNS có:
• IP: 192.168.2.1
• Netmask: 255.255.255.0
• DNS: trỏ về chính nó (192.168.2.1)
• Máy đã được nâng cấp lên DC và cài dịch vụ DNS.
Một máy Web server:
• IP: 192.168.2.2
• Netmask: 255.255.255.0
• DNS: trỏ về máy DNS(192.168.2.1)
• Máy được cài dịch vụ IIS và CA.
3.2. Công Cụ
Công cụ dùng để mô phỏng là Vmware cài 2 máy ảo là 2 server như trên
3.3. Các bước thực hiện
Quá trình mô phỏng được thực hiện tuần tự qua các bước:
Bước 1: Thiết lập thông số cơ bản:
Máy DNS server:
1.2. Tổng quan về SSLSSL là một sự Open bổ trợ của VPN trên thị trường. Nó được phong cách thiết kế chonhững giải pháp truy vấn từ xa và không phân phối những liên kết site-to-site. SSLVPNs cung ứng yếu tố bảo mật thông tin truy vấn tiên phong những ứng dụng web. Bởi vì SSL sửdụng trình duyệt web, nổi bật là những người sử dụng không phải chạy bất kể phầnmềm client đặc biệt quan trọng nào trên những máy tính của họ. SSL VPNs hoạt động giải trí ở tầng phiên ( session layer ) của quy mô tiêu chuẩn OSI.Và chính do client là một trình duyệt web, chỉ những ứng dụng đó mà chúng hổ trợ trìnhduyệt web, bằng mặc định, nó sẽ thao tác với một giải pháp VPN. Vì thế những ứngdụng như Telnet, FTP, SMTP, POP3, multimedia, mạng lưới hệ thống điện thoại di động IP, điềukhiển desktop từ xa, và những cái khác không thao tác với SSL VPNs chính do chúngkhông sử dụng trình duyệt web cho giao diện đầu cuối người dùng của họ. Tất nhiên, nhiều nhà cung ứng cũng sử dụng cả java hoặc ActiveX để nâng cao SSL VPNs bằngviệc hổ trợ những ứng dụng không phải là HTTP, những người mua là POP3, SMTPe-mail, và tập tin Microsoft Windows và san sẻ máy in. Ví dụ sự bổ trợ SSL VPNscủa Cisco tương hỗ những ứng dụng không phải là web ví dụ điển hình Citrix, WindowsTerminal Services, và nhiều cái khác. Thêm vào đó, một vài nhà cung ứng sử dụngjava hay ActiveX để phân phối những thành phần SSL VPNs khác, ví dụ điển hình nhưthêm vào những công dụng bảo mật thông tin cho việc xóa hết những dấu vết từ một hoạt độngcủa một người mua trên máy tính của họ sau khi SSL VPNs đã được kết thúc. Ciscochỉ sự bổ xung SSL VPN như là WebVPN. 1.3. Hoạt động của SSLĐiểm cơ bản của SSL là được phong cách thiết kế độc lập với tầng ứng dụng để đảm bảotính bí hiểm, bảo đảm an toàn và chống trá hình luồng thông tin qua Internet giữa hai ứng dụngbất kỳ, thí dụ như webserver và những trình duyệt ( browser ), do đó được sử dụng rộng rãitrong nhiều ứng dụng khác nhau trên thiên nhiên và môi trường Internet. Toàn bộ chính sách hoạt độngvà mạng lưới hệ thống thuật toán mã hóa sử dụng trong SSL được phổ cập công khai minh bạch, trừ khoáchia sẻ trong thời điểm tạm thời được sinh ra tại thời gian trao đổi giữa hai ứng dụng là tạo ngẫu nhiênvà bí hiểm so với người quan sát trên mạng máy tính. Ngoài ra, giao thức SSL còn đòihỏi ứng dụng chủ phải được xác nhận bởi một đối tượng người dùng lớp thứ ba ( CA ) thông quachứng chỉ điện tử ( digital certificate ) dựa trên mật mã công khai minh bạch ( thí dụ RSA ). Sau đâyta xem xét một cách khái quát chính sách hoạt động giải trí của SSL để nghiên cứu và phân tích Lever an toàncủa nó và những khả nǎng vận dụng trong những ứng dụng nhạy cảm, đặc biệt quan trọng là những ứngdụng về thương mại và thanh toán giao dịch điện tử. Giao thức SSL dựa trên hai nhóm con giao thức là giao thức ” bắt tay ” ( handshake protocol ) và giao thức ” bản ghi ” ( record protocol ). Giao thức bắt tay xácđịnh những tham số thanh toán giao dịch giữa hai đối tượng người dùng có nhu yếu trao đổi thông tin hoặc dữliệu, còn giao thức bản ghi xác lập khuôn dạng cho triển khai mã hóa và truyền tin haichiều giữa hai đối tượng người tiêu dùng đó. Khi hai ứng dụng máy tính, thí dụ giữa một trình duyệtweb và sever web, thao tác với nhau, sever và máy khách sẽ trao đổi ” lời chào ( hello ) dưới dạng những thông điệp cho nhau với xuất phát tiên phong dữ thế chủ động từ sever, đồng thời xác lập những chuẩn về thuật toán mã hóa và nén số liệu hoàn toàn có thể được áp dụnggiữa hai ứng dụng. Ngoài ra, những ứng dụng còn trao đổi ” số nhận dạng / khóa theophiên ” ( session ID, session key ) duy nhất cho lần thao tác đó. Sau đó ứng dụng khách ( trình duyệt ) nhu yếu có chứng từ điện tử ( digital certificate ) xác nhận của ứng dụngchủ ( web server ). Chứng chỉ điện tử thường được xác nhận thoáng đãng bởi một cơ quan trung gian ( Thẩm quyền xác nhận CA – Certificate Authority ) như RSA Data Sercurity hayVeriSign Inc., một dạng tổ chức triển khai độc lập, trung lập và có uy tín. Các tổ chức triển khai này cungcấp dịch vụ ” xác nhận ” số nhận dạng của một công ty và phát hành chứng từ duy nhấtcho công ty đó như thể bằng chứng nhận dạng ( identity ) cho những thanh toán giao dịch trên mạng, ởđây là những sever webserver. Sau khi kiểm tra chứng từ điện tử của sever ( sử dụng thuật toán mật mãcông khai, như RSA tại trình máy trạm ), ứng dụng máy trạm sử dụng những thông tintrong chứng từ điện tử để mã hóa thông điệp gửi lại sever mà chỉ có sever đócó thể giải thuật. Trên cơ sở đó, hai ứng dụng trao đổi khóa chính ( master key ) – khóa bímật hay khóa đối xứng – để làm cơ sở cho việc mã hóa luồng thông tin / tài liệu qua lạigiữa hai ứng dụng chủ khách. Toàn bộ Lever bảo mật thông tin và bảo đảm an toàn của thông tin / dữ liệuphụ thuộc vào một số ít tham số : • Số nhận dạng theo phiên thao tác ngẫu nhiên. • Cấp độ bảo mật thông tin của những thuật toán bảo mật thông tin vận dụng cho SSL. • Độ dài của khóa chính ( key length ) sử dụng cho lược đồ mã hóa thông tin. 1.4. Lịch sử tăng trưởng SSLNhư tất cả chúng ta đã biết có hai giao thức bảo mật thông tin quan trọng lớp luân chuyển ( Layer Transport ) có tầm quan trọng cao nhất so với sự bảo mật thông tin của những trình ứngdụng trên Web : đó là hai giao thức SSL và TLS.Nói chung, có một số ít năng lực để bảo vệ bằng mật mã lưu lượng dữ liệuHTTP. Ví dụ, vào những năm 1990, tập đoàn lớn CommerceNet đã yêu cầu S-HTTP mà vềcơ bản là một nâng cấp cải tiến bảo mật thông tin của HTTP. Một phần thực thi của S-HTTP đã làm chocó 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 NCSAmà 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ôngcộng và không lấy phí trên Internet ). Tuy nhiên, cùng thời gian Netscape Communication đã ra mắt SSL và mộtgiao thức tương ứng với phiên bản tiên phong của Netscape Navigator, Trái với tập đoànCommerceNet, Netscape Communications đã không tính phí những người mua của nó vềviệc thực thi giao thức bảo mật thông tin của nó. Kết quả, SSL trở thành giao thức điển hình nổi bật đểcung cấp những dịch vụ bảo mật thông tin cho lưu lượng tài liệu HTTP 1994 và S-HTTP lặng lẽbiến mất. Cho đến giờ đây, có ba phiên bản của 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 khi nào được tung ra bên ngoài. 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 tương quan đến sự hiện thân đơn cử của cuộc tiến công của đối tượng người dùng trunggian. Trong một nỗ lực nhằm mục đích dùng sự không chắc như đinh của công chúng về bảo mậtcủa SSL, Microsoft cũng đã giới thiệu giao thức PCT ( Private CommunicationTechnology ) cạnh tranh đối đầu trong lần tung ra Internet Explorer tiên phong của nó vào năm1996. Netscape Communications đã phản ứng lại sự thử thách PCT của Microsoft bằngcách ra mắt SSL 3.0 vốn xử lý những yếu tố trong SSL 2.0 và thêm 1 số ít tínhnăng mới. Vào thời gian này, Microsoft nhượng bộ và chấp thuận đồng ý tương hỗ SSL trong tất cảcác phiên bản ứng dụng dựa vào TCP / IP của nó ( mặc dầu phiên bản riêng của nó vẫnhỗ trợ PCT cho sự thích hợp 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ăm1996. Nó được thực thi trong tổng thể những trình duyệt chính gồm có ví dụ MicrosoftInternet Explorer 3.0 ( và những phiên bản cao hơn ), Netscape Navigator 3.0 ( và cácphiên bản cao hơn ), và Open. Như được đàm đạo ở phần sau trong chương này, SSL3. 0 đã được kiểm soát và điều chỉnh bởi IETF TLS WG. Thực tế, thông số kỹ thuật kỹ thuật giao thức TLS1. 0 dẫn xuất từ SSL 3.0. Hai phần tiếp theo tập trung chuyên sâu chỉ vào những giao thức SSL vàTLS ; giao thức PCT không được trình bầy thêm trong những bài viết sắp tới. 1.4. Ứng dụng SSL trong thương mại điện tửTrong thực tiễn, sự hiểu biết của người sử dụng về chính sách bảo mật thông tin được ” sắpđặt ” trong những thanh toán giao dịch điện tử trên mạng Internet là rất ít và mờ. Tất cả phần nhiều dựavào sự tin yêu ( trust ), ví dụ điển hình tên tuổi của những hãng có uy tín ( VisaCard, MasterCard, ) và mẫu sản phẩm có tính nǎng tốt của những hãng nổi tiếng ( Oracle, Microsoft, Netscape, ). Bảo mật và bảo đảm an toàn là yếu tố quan trọng trong việc quyết địnhsự tăng trưởng can đảm và mạnh mẽ thương mại điện tử hoặc lúc bấy giờ như cơ quan chính phủ điện tử ( e-government ) và tạo ý thức cho người mua và công chúng. Qua nghiên cứu và phân tích ví dụ củabảo mật trong giao thức SSL, cho ta thấy mặt khác của yếu tố : khả nǎng lựa chọncông nghệ và mức độ phụ thuộc vào vào công nghệ tiên tiến, khi kiến thiết xây dựng những ứng dụng nền tảngtrong đó có hạ tầng bảo mật thông tin thông tin. Việc tiến hành những mạng lưới hệ thống ứng dụng sử dụng hạ tầng tiếp thị quảng cáo Internetđòi hỏi có độ bảo mật thông tin cao ( đặc biệt quan trọng trong ngân hàng nhà nước, kinh tế tài chính, quốc phòng ) cần phảiđược thiết kế xây dựng dựa trên sơ đồ gồm những lớp bảo mật thông tin nhiều tầng độc lập ( thí dụ : giaothức Giao dịch điện tử bảo mật thông tin SET ( Secure Electronic Transaction ), Giao thức khoáInternet IKP ( Internet Keyed Protocol ) hoặc PGP ( Pretty Good Privacy ), thậm chí còn cảphần cứng, nhằm mục đích hạn chế tối đa những ” lỗ hổng ” bảo mật thông tin của mạng lưới hệ thống giao thương mua bán điệntử. Ngoài ra cũng cần chú ý quan tâm những mẫu sản phẩm về bảo mật thông tin ứng dụng lúc bấy giờ trên mạngmáy tính phần đông được ý tưởng từ Mỹ, được bảo lãnh và trấn áp ngặt nghèo bởi luậtpháp Mỹ dẫn đến khi thực hành thực tế kiến thiết xây dựng và tiến hành những mạng lưới hệ thống thông tin và giaodịch thương mại điện tử của tất cả chúng ta cần thận trọng và xem xét. Chương 2 : Cấu Trúc Và Các Giao Thức Bảo Mật2. 1. Cấu trúc SSLCấu trúc của SSL và giao thức SSL tương ứng được minh họa trong hình1. 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 thông tin ) trung gian giữa lớp luân chuyển ( Transport Layer ) và lớp ứng dụng ( ApplicationLayer ). SSL được xếp lớp lên trên một dịch vụ luân chuyển khuynh hướng nối kết và đángtin cậy, ví dụ điển hình như được phân phối bởi TCP. Về năng lực, nó hoàn toàn có thể phân phối cácdịch vụ bảo mật thông tin cho những giao thức ứng dụng tùy ý dựa vào TCP chứ không chỉ HTTP.Thực tế, một ưu điểm chính của những giao thức bảo mật thông tin lớp luân chuyển ( Transportlayer ) 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ĩalà chúng hoàn toàn có thể được sử dụng để bảo vệ bất kể giao thức ứng dụng được xếp lớp lêntrên TCP một cách trong suốt. Hình 1.1 minh họa một số ít giao thức ứng dụng điển hìnhbao 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áctừ ghép giao thức tương ứng chỉ định việc sử dụng SSL ). Tuy nhiên, chú ý quan tâm rằng SSL có một xu thế client-server can đảm và mạnh mẽ và thật sựkhông cung ứng những nhu yếu của những giao thức ứng dụng ngang hàng. Hình 1.1 : Cấu trúc của SSL và giao thức SSL10Tóm lại, giao thức SSL cung ứng sự bảo mật thông tin truyền thông online vốn có ba đặc tính cơ bản : 1. Các bên tiếp xúc ( nghĩa là client và server ) hoàn toàn có thể xác nhận nhau bằng cáchsử dụng mật mã khóa chung. 2. Sự bí hiểm của lưu lượng tài liệu được bảo vệ vì nối kết được mã hóa trongsuốt sau khi một sự thiết lập quan hệ khởi đầu và sự thương lượng khóa session đã xảyra. 3. Tính xác nhận và tính toàn vẹn của lưu lượng tài liệu cũng được bảo vệ vì cácthông báo được xác nhận và được kiểm tra tính toàn vẹn một cách trong suốt bằng cáchsử dụng MAC.Tuy nhiên, điều quan trọng cần quan tâm là SSL không ngăn những cuộc tấn côngphân tích lưu lượng. Ví dụ, bằng cách xem xét những địa chỉ IP nguồn và đích khôngđược mã hóa và những sô cổng TCP, hoặc xem xét lượng tài liệu được truyền, một ngườiphân tích lưu lượng vẫn hoàn toàn có thể xác lập những bên nào đang tương tác, những loại dịch vụđang được sử dụng, và nhiều lúc ngay cả dành được thông tin về những mối quan hệ doanhnghiệp hoặc cá thể. Hơn nữa, SSL không ngăn những cuộc tiến công có khuynh hướng dựavào phần thực thi TCP, ví dụ điển hình như những cuộc tiến công làm tràn ngập TCP SYNhoặ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 đangsử dụng SSL. Nói chung, có ba năng lực để xử lý yếu tố này : 1. Sử dụng những số cổng chuyên được dùng được dành riêng bởi Internet AsignedNumbers Authority ( IANA ). Trong trường hợp này, 1 số ít cổng riêng không liên quan gì đến nhau phải đượcgán cho mọi giao thức ứng dụng vốn sử dụng SSL. 2. Sử dụng số cổng chuẩn cho mọi giao thức ứng dụng và để thương lượng cáctùy chọn bảo mật thông tin như thể một phần của giao thức ứng dụng ( giờ đây được chỉnh sửa đôichút ). 113. Sử dụng một tùy chọn TCP để thương lượng việc sử dụng một giao thức bảomật, ví dụ điển hình như SSL trong suốt quy trình tiến độ thiết lập nối kết TCP thường thì. Sự thương lượng dành riêng cho ứng dụng của những tùy chọn bảo mật thông tin ( nghĩa là khảnăng thứ hai ) có khuyết điểm là yên cầu mọi giao thức ứng dụng được chỉnh sửa đểhiểu tiến trình thương lượng. Ngoài ra, việc xác lập một tùy chọn TCP ( nghĩa là khảnăng thứ ba ) là một giải pháp tốt, nhưng đó không được luận bàn tráng lệ cho đếnbây giờ. Thực tế, những số cổng riêng không liên quan gì đến nhau đã được dành riêng và được gán bởi IANAcho mọi giao thức ứng dụng vốn hoàn toàn có thể chạy trên SSL hoặc TLS ( nghĩa là khả năngthứ nhất ). Tuy nhiên, hãy chú ý quan tâm việc sử dụng những số cổng riêng không liên quan gì đến nhau cũng có khuyếtđiểm là yên cầu hai nối kết TCP nếu client không biết những gì mà server tương hỗ. Trướctiên, client phải nối kết với cổng bảo đảm an toàn và sau đó với cổng không bảo đảm an toàn hay ngượclại. Rất hoàn toàn có thể những giao thức sau này sẽ hủy bỏ giải pháp này và tìm năng lực thứhai. Ví dụ, SALS ( Simple Authentication và Security Layer ) xác lập một tương thích đểthêm sự tương hỗ xác nhận vào những giao thức ứng dụng dựa vào liên kết. Theo thông số kỹ thuật kỹthuật SALS, việc sử dụng những chính sách xác nhận hoàn toàn có thể thương lượng giữa client vàserver của một giao thức ứng dụng đã cho. Các số cổng được gán bởi IANA cho những giao thức ứng dụng vốn chạy trênSSL / TLS được tóm tắt trong bảng 1.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ố ) đồng nhất vào những từghép của những giao thức ứng dụng tương ứng ( trong 1 số ít thuật ngữ khởi đầu, S đượcsử dụng và được thêm tiền tố một cách không đồng nhất và một số ít từ ghép ). 12B ảng 1.2 : Các số cổng được gán cho những giao thức ứng dụng chạy trênTLS / SSL.Nói chung, một session SSL có trạng thái và giao thức SSL phải khởi tạo vàduy trì thông tin trạng thái ở một trong hai phía của session. Các thành phần thông tintrạng thái session tương ứng gồm có một session ID, một ghi nhận ngang hàng, một chiêu thức nén, một thông số kỹ thuật mật mã, một khóa mật chính và một cờ vốn chỉđịnh việc session hoàn toàn có thể liên tục lại hay không, được tóm tắt trong bảng 1.3. Mộtsession SSL hoàn toàn có thể được sử dụng trong 1 số ít liên kết và những thành phần thông tintrạng thái nối kết tương ứng được tóm tắt trong bảng 1.4. Chúng baogồm những tham số mật mã, ví dụ điển hình như những chuỗi byte ngẫu nhiên server và client, những khóa mật MAC ghi server và client, những khóa ghi server và client, một vector khởitạo và một số ít chuỗi. Ở trong hai trường hợp, điều quan trọng cần quan tâm là những phía giaotiếp phải sử dụng nhiều session SSL đồng thời và những session có nhiều nối kết đồngthời. Bảng 1.3 Các thành phần thông tin trạng thái Session SSL13Bảng 1.4 Các thành phần thông tin trạng thái nối kết SSLNhư được minh họa trong hình 1.1, giao thức SSL gồm hai phần chính, SSLRecord Protocol và một số ít 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 luân chuyển định hướngnối kết và đáng an toàn và đáng tin cậy, ví dụ điển hình như được cung ứng bởi TCP và cungcấp sự xác nhận nguồn gốc thông tin, sự bí hiểm tài liệu và tài liệu. • Các dịch vụ toàn vẹn ( gồm có 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 để cungcấp sự tương hỗ cho việc quản trị 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 giaothức này là một giao thức xác nhận và trao đổi khóa vốn hoàn toàn có thể được sử dụng đểthương lượng, khởi tạo và đồng điệu hóa những tham số bảo mật thông tin và thông tin trạng tháitương ứng được đặt ở một trong hai điểm cuối của một session hoặc nối kết SSL. 14S au khi SSL Handshake Protocol đã hoàn tất, tài liệu ứng dụng hoàn toàn có thể được gửivà được nhận bằng cách sử dụng SSL Record Protocol và những tham số bảo mật thông tin đượcthương lượng và những thành phần thông tin trạng thái. 2.2. Các Giao Thức Bảo Mật SSLSSL Record Protocol nhận tài liệu từ những giao thức con SSL lớp cao hơn và xửlý việc phân đoạn, nén, xác nhận và mã hóa dữ liệu. Chính xác hơn, giao thức này lấymột khối tài liệu có kích cỡ tùy ý làm dữ liệu nhập và tọa một loạt những đoạn dữ liệuSSL làm dữ liệu xuất ( hoặc còn được gọi là những bản ghi ) nhỏ hơn hoặc bằng 16,383 byte. 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 tài liệu thôđến một bản ghi SSL Plaintext ( bước phân đoạn ), SSL Compressed ( bước nén ) và SSLCiphertext ( bước mã hóa ) được minh họa trong hình 1.5. Sau cùng, mỗi bản ghi SSLchứa những trường thông tin sau đây : 15 – Loại nội dung ; – Số phiên bản của giao thức ; – Chiều dài ; – Tải trọng tài liệu ( được nén và được mã hóa tùy ý ) ; – MAC.Loại nội dung xác lập giao thức lớp cao hơn vốn phải được sử dụng để sau đóxử lý tải trọng tài 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 lập phiên bản SSL đang sử dụng ( thường làversion 3.0 ) Mỗi tải trọng tài liệu bản ghi SSL được nén và được mã hóa theo phương thứcnén hiện hành và thông số kỹ thuật mật mã được xác lập cho session SSL.Lúc khởi đầu mỗi session SSL, chiêu thức nén và thông số kỹ thuật mật mã thườngđược xác lập là rỗng. Cả hai được xác lập trong suốt quy trình thực thi khởi đầu SSLHandshake Protocol. Sau cùng, MAC được thêm vào mỗi bản ghi SSL. Nó cung cấpcác dịch vụ xác nhận nguồn gốc thông tin và tính toàn vẹn tài 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ố kỹ thuật mật mã của trạng thái session hiện hành. Theo mặc định, SSLRecord Protocol sử dụng một cấu trúc MAC vốn tương tự như nhưng vẫn khác với cấu trúcHMAC hơn. Có ba điểm độc lạ chính giữa cấu trúc SSL MAC và cấu trúc HMAC : 1. Cấu trúc SSL MAC có 1 số ít chuỗi trong thông tin trước khi hash để ngăncác hình thức tiến công xem lại riêng không liên quan gì đến nhau. 2. Cấu trúc SSL MAC có chiều dài bản ghi. 3. Cấu trúc SSL MAC sử dụng những toán tử ghép, trong khi cấu trúc MAC sửdụng moduloe cộng 2.16 Tất cả những điểm độc lạ này hiện hữu hầu hết vì cấu trúc SSL MAC đượcsử dụng trước cấu trúc HMAC trong hầu hết tổng thể thông số kỹ thuật kỹ thuật giao thức bảomật Internet. Cấu trúc HMAC cũng được sử dụng cho thông số kỹ thuật kỹ thuật giao thức TLSgần đây hơn. Như được minh họa trong hình 1.5, một số ít giao thức con SSL được xếp lớp trênSSL Record Protocol. Mỗi giao thức con hoàn toàn có thể tham chiếu đến những loại thông tin 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 lập 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 những cảnh báo nhắc nhở thông quaSSL Record Protocol. Mỗi cảnh báo nhắc nhở gồm 2 phần, một mức cảnh báo nhắc nhở 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. Sau cùng, SSL ChangeCipherSpec Protocol được sử dụng để đổi khác giữa mộtthông số mật mã này và một thông số kỹ thuật mật mã khác. Mặc dù thông số kỹ thuật mật mã thườngđược biến hóa ở cuối một sự thiết lập quan hệ SSL, nhưng nó cũng hoàn toàn có thể được thayđổi vào bất kể thời gian sau đó. Ngoài những giao thức con SSL này, một SSL Application Data Protocol đượcsử dụng để chuyển trực tiếp tài liệu ứng dụng đến SSL Record Protocol. SSL Handshake Protocol là giao thức con SSL chính được xếp lớp trên SSLRecord Protocol. Kết quả, những thông tin thiết lập quan hệ SSL đượccung cấp cho lớp bản ghi SSL nơi chúng được phủ bọc trong một hoặc nhiều bản ghi17SSL vốn được giải quyết và xử lý và được chuyển như được xác lập bởi chiêu thức nén và thôngsố mật mã của session SSL hiện hành và những khóa mật mã của nối kết SSL tương ứng. Mục đích của SSL Handshake Protocol là nhu yếu một client và server thiết lập và duytrì thông tin trạng thái vốn được sử dụng để bảo vệ những cuộc liên lạc. Cụ thể hơn, giaothức phải nhu yếu client và server chấp thuận đồng ý một phiên bản giao thức SSL chung, chọn phương pháp nén và thông số kỹ thuật mật mã, tùy ý xác nhận nhau và tạo một khóa mậtchính mà từ đó những khóa session khác nhau dành cho việc xác nhận và mã hóa thôngbáo hoàn toàn có thể được dẫn xuất từ đó. Tóm lại, việc thực thi SSL Handshake Protocol giữa một client C và một serverS hoàn toàn có thể được tóm tắt như sau ( những thông tin được đặt trong những dấu ngoặc vuông thìtùy ý ) : 1 : C -> S : CLIENTHELLO2 : S -> C : SERVERHELLO [ CERTIFICATE ] [ SERVERKEYEXCHANGE ] [ CERTIFICATEREQUEST ] SERVERHELLODONE3 : C -> [ CERTIFICATE ] CLIENTKEYEXCHANGE [ CERTIFICATEVERIFY ] CHANGECIPHERSPECFINISHED184 : S -> C : CHANGECIPHERSPECFINISHEDHình 1.6 : Giao tiếp giữa server và clienKhi Client C muốn liên kết với server S, nó thiết lập một nối kếtTCP với cổng HTTPS ( vốn không được đưa vào phần miêu tả giao thức ) và gởi mộtthông báo CLIENTHELLO đến server ở bước 1 của sự thực thi SSL HandshakeProtocol. Client cũng hoàn toàn có thể gởi một thông tin CLIENTHELLO nhằm mục đích phản hồi lạimột thông tin HELLOREQUEST hoặc dữ thế chủ động thương lượng lại những tham số bảomật của một nối kết hiện có. Thông báo CLIENTHELLO gồm có những trường sau đây : – Số của phiên bản SSL cao nhất được bộc lộ bởi client ( thường là 3.0 ). 19 – Một cấu trúc ngẫu nhiên do client tạo ra gồm một tem thời hạn 32 bit có dạngUNIX chuẩn và một giá trị 28 byte được tạo ra bởi một bộ tạo số giả ngẫu nhiên. – Một định danh session mà client muốn sử dụng cho nối kết này. – Một list những bộ mật mã client tương hỗ. – Một list những giải pháp nén mà client tương hỗ. Chú ý rằng trường session identity ( định danh session ) nên rỗng nếu sessionSSL hiện không sống sót hoặc nếu client muốn tạo những tham số bảo mật thông tin mới. Ở mộttrong hai trường hợp, một trường session identity không rỗng là xác lập một sessionSSL hiện có giữa client và server ( nghĩa là một session có những tham số bảo mật thông tin màclient muốn sử dụng lại. ). Định danh session hoàn toàn 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 giải trí. Cũng chú ý quan tâm rằng list những bộ mậtmã được tương hỗ, được chuyển từ client đến server trong thông tin CLIENTHELLO, chứa những tổng hợp thuật toán mật mã được tương hỗ bởi client theo thứ tự ưu tiêm. Mỗi bộmật mã xác lập một thuật toán trao đổi khóa và một thông tin mật mã. Server sẽchọn một bộ mật mã hoặc nếu những lựa chọn hoàn toàn có thể gật đầu được không được trìnhbầy, trả về một thông tin lỗi và đóng nối kết một cách tương thích. Sau khi đã gởi thôngbáo CLIENTHELLO, client đợi một thông tin SERVERHELLO. Bất kỳ thông báokhác được trả về bởi server ngoại trừ một thông tin HELLOREQUEST được xem nhưlà một lỗi vào thời gian này. Ở bước 2, server giải quyết và xử lý thông tin CLIENTHELLO và cung ứng bằng một thôngbáo lỗi hoặc thông tin SERVERHELLO. Tương tự như thông tin CLIENTHELLO, thông tin SERVERHELLO có những trường sau đây : – Một số phiên bản server chứa phiên bản thấp hơn của phiên bản được đề nghịbởi client trong thông tin CLIENTHELLO và được tương hỗ cao nhất bở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 hạn 32 bit códạng UNIX chuẩn và một giá trị 28 bit được tạo ra bởi một bộ tạo số ngẫu nhiên. 20 – Một định danh session tương ứng với nối kết này. – Một bộ mật mã được chọn từ bởi server từ list những bộ mật mã được hỗtrợ bởi client. – Một chiêu thức nén được chọn bởi server từ list những thuật toán nénđược tương hỗ bởi client. Nếu định danh session trong thông tin CLIENTHELLO không rỗng, server tìmtrong cache session của nó nhằm mục đích tìm ra một mục tương hợp. Nếu mục tương hợp đượctì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 sessiontương ứng, server cung ứng bằng cùng một giá trị như được cung ứng bởi client. Chỉ địnnày là một session được liên tục lại và xác lập rằng cả hai phía phải triển khai trựctiếp với những thông tin CHANGECIPHERSPEC và FINISHED được trình diễn thêmbên dưới. Nếu không, trường này chứa một giá trị khác nhận biết một session mới. Server cũng hoàn toàn có thể trả về một trường định danh session rỗng để biểu lộ rằng session sẽkhông được tàng trữ và do đó không hề được liên tục sau đó. Cũng quan tâm rằng trongthông báo SERVERHELLO, server chọn một bộ mật mã và một giải pháp nén từcác list được cung ứng bởi client trong thông tin CLIENTHELLO. Các thuậttoán trao đổi khóa, xác nhận, mã hóa và xác nhận thông tin được xác lập bởi bộ mãđược chọn bởi server và được làm lộ ra trong thông tin SERVERHELLO. Các bộ mậtmã vốn đã được xác lập trong giao thức SSL về cơ bản giống như bộ mật mã đã xácđịnh cho TLS ( như được tóm tắt ở những bản 1.4 đến 1.7 trong những bài viết trước ). Ngoài thông tin SERVERHELLO, server cũng phải gởi những thông tin khácđế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ởichứng nhận site của nó đến client trong một thông tin CERTIFICATE tương ứng. Chứng nhận phải thích hợp cho thuật toán trao đổi khóa của bộ mật mã được chọn vàthường là một ghi nhận X. 509 v3. Cùng loại thông tin sẽ được sử dụng sau đó chosự cung ứng của client so với thông tin sẽ được sử dụng sau đó cho sự phân phối củaclient so với thông tin CERTIFICATERequest của server. Trong trường hợp của cácchứng nhận X. 509 v3, một ghi nhận hoàn toàn có thể thực sự tham chiếu đến hàng loạt một21chuỗi những ghi nhận, được sắp xếp theo thứ tự với ghi nhận của đối tượng người dùng gởitrước tiên theo sau là bất kể ghi nhận CA triển khai theo trình tự hướng đến một CAgốc ( vốn sẽ được gật đầu bởi client ). Tiếp theo, server hoàn toàn có thể gởi một thông tin SERVERKEYEXCHANGE đếnclient nếu nó không có ghi nhận, một ghi nhận vốn hoàn toàn có thể được sử dụng chỉ đểxác nhận những chữ ký kỹ thuật số hoặc sử dụng thuật toán trao đổi khóa dựa vào tokenFORITEZZA ( KEA ). Rõ ràng, thông tin này không được nhu yếu nếu chứng nhậnsite gồm một khóa chung RSA vốn hoàn toàn có thể được sử dụng trong việc mã hóa. Ngoài ra, một server không nặc danh hoàn toàn có thể tùy ý nhu yếu một ghi nhận cá thể để xác thựcclient. Do đó, nó gởi một thông tin CERTIFICATE Request đến client. Thông báonày chứa một list những loại ghi nhận được nhu yếu, được phân loại theo thứ tựưu tiên của server cũng như một list những tên được phân biệt cho những CA có thểchấp nhận. Ở cuối bước 2, server gởi một thông tin SERVERHELLO Done đến clientđể chỉ định sự kết thúc SERVERHELLO và những thông tin đi kèm. Sau khi nhận SERVERHELLO và những thông tin đi kèm, client xác nhận rằngchứng nhận site server ( nếu được phân phối ) là hợp lệ và kiểm tra nhằm mục đích bảo vệ rằngcác thông số kỹ thuật bảo mật thông tin được cung ứng trong thông tin SERVERHELLO hoàn toàn có thể đượcchấp nhận. Nếu server nhu yếu sự xác nhận client, client gởi một thông báoCERTIFICATE vốn chứa một ghi nhận cá thể cho khóa chung của người dùngđến server ở bước 3. Tiếp theo, client gởi một thông tin CLIENTKEYEXCHANGEcó dạng nhờ vào 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 nhận server và trao đổi khóa, client tạomộ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 trongchứng nhận site hoặc khóa RSA trong thời điểm tạm thời từ thông tin SERVERKEYEXCHANGE vàgởi tác dụng quay trở lại server trong thông tin CLIENTKEYEXCHANGE. Lần lượt serversử dụng khóa riêng tương ứng để giải thuật khóa mật chính. – Nếu những token FORTEZZA được sử dụng để trao đổi khóa, client dẫn xuấtmộ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ử22dụng khóa chung từ ghi nhận server cùng với một số ít tham số riêng trong token củaclient. Client gởi những tham số chung thiết yếu cho server để cũng tạo TEK, sử dụng cáctham sô riêng của nó. Nó tạo một khóa mật chính, phủ bọc nó bằng cách sử dụng TEKvà gởi hiệu quả cùng với một số ít vector khởi tạo đến server như thể một phần của thôngbáo CLIENTKEYEXCHANGE. Lần lượt, server hoàn toàn có thể giải thuật khóa mật chính mộtcách thích hợp. Thuật toán trao đổi khóa này không được sử dụng thoáng đãng. Nếu sự xác nhận client được nhu yếu, client cũng gởi một thông báoCERTIFICATEVERIFY đến server. Thông báo này được sử dụng để phân phối sự xácthực rõ ràng định danh của người dùng dựa vào ghi nhận những nhân. Nó chỉ được gởitheo sau một chứng từ client vốn có năng lực tạo chữ ký ( toàn bộ ghi nhận ngoại trừcác ghi nhận chứa những tham số DiffeHallman cố định và thắt chặt ). Sau cùng, client hoàn tấtbước 3 bằng cách gởi một thông tin CHANGECIPHERSPEC và một thông báoFINISHED tương ứng đến server. Thông báo FINISHED luôn được gởi ngay lập tứcsau thông tin CHANGECIPERSPEC để xác nhận rằng những tiến trình trao đổi khóa vàxác thực đã thành công xuất sắc. Thực tế, thông tin FINISHED là thông tin tiên phong vốn đượcbảo vệ bằng những thuật toán mới được thương lượng và những khóa session. Nó chỉ có thểđược tạo và được xác nhận nếu những khóa này được thiết lập một cách tương thích ở cảhai phía. Không yên cầu sự báo nhận thông tin FINISHED ; những phía hoàn toàn có thể khởi đầu gởidữ liệu được mã hóa ngay lập tức sau khi đã gởi thông tin FINISHED. Việc thực thiSSL Handshake Protocol hoàn tất bằng việc cũng nhu yếu server gởi một thông báoCHANGECIPHERSPEC và một thông tin FINISHED tương ứng đến client ở bước 4. Sau khi sự thiết lập SSL hoàn tất, một nối kết bảo đảm an toàn được thiết lập giữa clientvà server. Nối kết này giờ đây hoàn toàn có thể được sử dụng để gởi tài liệu ứng dụng vốn đượcbao bọc bởi SSL Record Protocol. Chính xác hơn, tài liệu ứng dụng hoàn toàn có thể được phânđoạn, được nén, hoặc được mã hóa và đước xác nhận theo SSL Record Protocol cũngnhư thông tin trạng thái session và nối kết vốn giờ đây được thiết lập ( tùy thuộc việcthực thi SSL Handshake Protocol ). SSL Handshake Protocol hoàn toàn có thể được rút ngắn nếu client và server quyết địnhtiếp tục lại một session SSL được thiết lập trước đó ( và vẫn được tàng trữ ) hoặc lặp lại23một session SSL hiện có. Trong trường hợp này, chỉ ba dòng thông tin và tổng cộngsáu thông tin được nhu yếu. Các dòng thông tin tương ứng hoàn toàn có thể được tóm tắt nhưsau : 1 : C -> S : CLIENTHELLO2 : S -> C : SERVERHELLOCHANECIPHERSPECFINISHED3 : S -> C : CHANGECIPHERSPECFINISHEDỞ bước 1, client gởi một thông tin CLIENTHELLO đến server vốn có mộtđịnh danh session cần được liên tục lại. Lần lượt server kiểm tra cache session của nóđể tìm một mục tương hợp. Nếu một mục tương hợp được tìm thấy, server muốn tiếptục lại nối kết bên dưới trạng thái session đã xác lập, nó trả về một thông báoSERVERHELLO với cùng một định danh session ở bước 2. Vào thời gian này, cảclient lẫn server phải gởi những thông tin CHANGECIPHERSPEC và FINISHED đếnnhau ở 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 tài liệu ứng dụngNhững bổ trợ SSL Client ( SSL Client Implementations ) Một nguyên do chính mà những người quản trị mạng nhu yếu đưa ra nhữngbổ sung SSL VPN những giao thức SSL VPNs mà không nhu yếu bất kể loại phầnmềm đặc biệt quan trọng của VPN Client nào để được thiết lập trước trên những máy tính để bàncủa người sử dụng. Tất nhiên, người sử dụng biết một vài ứng dụng thiết yếu, giốngnhư một trình duyệt web đươc hổ trợ SSL, đặc trưng với cả Java và ActiveX cũng đượchổ trợ, và phần nhiều người sử dụng đã cài những điều này từ một sự setup khởi đầu trênmáy tính. 24C ó 3 loại SSL Client Implementation tổng quát : • Clientless • Thin client • Network clientBởi vì chỉ một trình duyệt web được nhu yếu trên máy tính người sử dụng, SSLclient thường thì được xem như thể “ Clientless ” hoặc “ webified ”. Vì thế SSL VPNthỉnh thoảng được gọi là clientless VPN. Điều trở ngại chính của một clientless VPNlà chỉ giao thông vận tải dạng web hoàn toàn có thể được bảo vệ. Đặc thù của một Thin client là ứng dụng java hoặc ActiveX đã tải xuống thôngqua SSL VPN đến máy tính người sử dụng. Nó được cho phép một tập hợp nhỏ những ứngdụng không phải là web được luân chuyển trải qua SSL VPN. Trong việc truy cậpdựa vào mạng, một SSL client được setup trên máy tính của người sử dụng ; tuynhiên, đặc tính này được tải xuống máy tính của người sử dụng. SSL ProtectionSSL VPN không thiết yếu cung ứng việc bảo vệ của tài liệu ở tầng network, ví dụ điển hình như IPSec, PPTP, và L2TP. Client SSL VPN phân phối việc bảo vệ chonhững ứng dụng web ở tầng Session ( tầng thứ 5 ) mà chúng sử dụng trình duyệt web. Vì thế, nó sử dụng việc bảo vệ giao thông vận tải ở một vài thứ được số lượng giới hạn, cho ứng dụnggiao thông được bảo vệ, một vài cách sự truy vấn của người sử dụng đến ứng dụngphải trải qua một trình duyệt web. Tất nhiên, bất kể một cách liên kết kiểu HTTP cóthể thuận tiện được bảo vệ do tại người sử dụng sử dụng trình duyệt web cho kiểu chứcnăng này, nhưng điều này hoàn toàn có thể Open những yếu tố cho những kiểu ứng dụngkhác, ví dụ điển hình như Telnet, POP3, SMTP, SNMP, ping, traceroute, FTP, IPtelephony, Citrix, Oracle’s SQL * net, tập tin và việc chia sẽ máy in thông quaWindows hoặc Unix và nhiều thứ khác. 25C hương 3 : Mô phỏng lấy certificate SSL trong HTTPS3. 1. Chuẩn bịMô hình mạng cần để triển khai mô phỏng gồm có : Một máy DNS có : • IP : 192.168.2.1 • Netmask : 255.255.255.0 • DNS : trỏ về chính nó ( 192.168.2.1 ) • Máy đã được tăng cấp lên DC và cài dịch vụ DNS.Một máy Web server : • IP : 192.168.2.2 • Netmask : 255.255.255.0 • DNS : trỏ về máy DNS ( 192.168.2.1 ) • Máy được cài dịch vụ IIS và CA. 3.2. Công CụCông cụ dùng để mô phỏng là Vmware cài 2 máy ảo là 2 server như trên3. 3. Các bước thực hiệnQuá trình mô phỏng được triển khai tuần tự qua những bước : Bước 1 : Thiết lập thông số kỹ thuật cơ bản : Máy DNS server :

Source: https://vh2.com.vn
Category : Tin Học