tìm hểu giao thức ssl và ứng dụng bảo mật trong hệ thống mạng nội bộ

tìm hểu giao thức ssl và ứng dụng bảo mật trong hệ thống mạng nội bộ

KHOA ĐIỆN - ĐIỆN TỬ

BỘ MÔN ĐIỆN TỬ - VIỄN THÔNG

-ĐỒ ÁN MÔN HỌC 3 NGÀNH:CÔNG NGHỆ KỸ THUẬT MÁY TÍNH

Đại Học Sư Phạm Kỹ Thuật

Khoa Điện – Điện Tử

Bộ Môn Điện Tử Viễn Thông

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆTNAM

Độc Lập – Tự Do – Hạnh Phúc

Ngày……tháng … năm 201

PHIẾU CHẤM ĐỒ ÁN MÔN HỌC…

(Dành cho người hướng dẫn) 1 Họ tên sinh viên : ………

MSSV:

……….……… … MSSV:……

2 Tên đề tài : ………

………

3 Người hướng dẫn : ………

………

4 Những ưu điểm của Đồ án : ………

… ………

………

………

………

Những thiếu sót của Đồ án: ………

………

………

………

………

5 Đề nghị : Được bảo vệ:  Bổ sung để được bảo vệ:  Không được bảo vệ:  6 Các câu hỏi sinh viên phải trả lời trước Tổ chấm ĐAMH: a)………

………

b)………

………

c) ………

……….………

Đánh giá Điểm (Số và chữ):………

CHỮ KÝ và HỌ TÊN

Phần A GIỚI THIỆU

LỜI NÓI ĐẦU

Lời đầu tiên nhóm thực hiện đề tài xin cảm ơn thầy cô giáo chuyên ngành điện

tử, cảm ơn thầy Lê Minh đã hướng dẫn tận tình nhóm thực hiện đề tài trong quá trình thực hiện đồ án này

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 SSL 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 Giao thức SSL được hình thành và phát triển đầu tiên nǎm 1994 bởi nhóm nghiên cứu

Netscape dẫn dắt bởi Elgammal, và ngày nay đã trở thành chuẩn bảo mật thực hành trên mạng Internet Phiên bản SSL hiện nay là 3.0 và vẫn đang tiếp tục được bổ sung và hoàn thiện

Do kiến thức còn hạn hẹp và trình độ về chuyên môn còn hạn chế nên sẽ khó tránh khỏi những thiếu sót,khuyết điểm.Rất mong được sự đóng góp ý kiến và chỉ bảo nhiệt tình từ phía các thầy cô để đề tài được hoàn thiện hơn

Tp.HCM, Tháng 1 năm 2012

MỤC LỤC

Lời nói đầu 2

Mục lục 3

Phần B Nội dung Chương 1: SSL và ứng dụng 5

1.1 Tổng quan về Secure Socket Layer 5

1.2 HTTPS 21

1.3 SMTPS 24

1.4 POPS 28

Chương 2: Ứng dụng SSL cho web và mail server trong mạng nội bộ 31

2.1 Mô hình mạng 31

2.2 Các bước thực hiện triển khai SSL 58

Chương 3: Kết luận 63

3.1 Kết quả đạt được 63

3.2 Hạn chế 63

3.3 Hướng phát triển 63

Phần C Tài liệu tham khảo 1 Tài liệu tham khảo 65

2 Lời kết 65

Phần B NỘI DUNG

Chương 1:SSL VÀ ỨNG DỤNG

1.1.Tổng quan về Secure Socket Layer

1.1.1.Mở đầu

- Bảo mật cho dữ liệu truyền trên Internet ngày càng trở nên cần thiết do số lượng cũng như mức độ quan trọng của các dữ liệu này ngày càng cao Ngày nay, người dùng Internet trao đổi rất nhiều loại thông tin trên mạng từ trao đổi thư điện tử thông thường đến các thông tin chi tiết trong thẻ tín dụng của mình, do đó họ muốn những dữ liệu đó phải được bảo mật khi truyền trên mạng công cộng

- Để làm được điều này người ta đã ứng dụng giao thức SSL để bảo vệ các dữ liệu trong quá trình trao đổi giữa tất cả các dịch vụ mạng sử dụng TCP/IP để hỗ trợ các tác vụ truyền thông mạng giữa máy chủ và máy khách

- Giao thức SSL đầu tiên do Netscape phát triển, mục đích để bảo mật dữ liệu gửi/nhận trên Internet của các giao thức thuộc lớp ứng dụng như HTTP, LDAP hay POP3 SSL sử dụng giao thức TCP để cung cấp các kết nối bền vững, bảo mật và được xác thực giữa các điểm cuối với nhau (ví dụ như giữa client và server) Mặc dù có thể sử dụng SSL để bảo vệ dữ liệu liên quan đến bất kỳ dịch

vụ nào, nhưng SSL chủ yếu được dùng trong các ứng dụng HTTP (server và client) Ngày nay hầu hết các HTTP server đều hỗ trợ các phiên SSL, ở phía client các trình duyệt Internet Explorer và Netscape Navigator đều hỗ trợ SSL

Hình 1.1: SSL giữa tầng ứng dụng và tầng TCP/IP

1.1.2.Nhiệm vụ và cấu trúc của SSL

- Cấu trúc của SSL và giao thức SSL tương ứng được minh họa trong hình 2 (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 2 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.2 : Cấu trúc SSL

Những mục đích chính của việc phát triển SSL là:

• Xác thực server và client với nhau: SSL hỗ trợ sử dụng các kỹ thuật mã hoá khoá chuẩn (mã hoá sử dụng khoá công khai) để xác thực các đối tác truyền thông với nhau Hầu hết các ứng dụng hiện nay xác thực các client bằng cách sử dụng chứng chỉ số, SSL cũng có thể sử dụng phương pháp này để xác thực client

• Đảm bảo toàn vẹn dữ liệu: trong một phiên làm việc, dữ liệu không thể bị làm hỏng dù vô tình hay cố ý

• Bảo vệ tính riêng tư: dữ liệu trao đổi giữa client và server phải được bảo

vệ, tránh bị đánh cắp trên đường truyền và chỉ có đúng người nhận mới có thể đọc được các dữ liệu đó Các dữ liệu được bảo vệ bao gồm các những

dữ liệu liên quan đến chính hoạt động giao thức (các thông tin trao đổi trong quá trình thiết lập phiên làm việc SSL) và các dữ liệu thực trao đổi trong phiên làm việc

- Thực tế SSL không phải là một giao thức đơn mà là một bộ các giao thức, có thể được chia làm 2 lớp:

1 Giao thức đảm bảo sự an toàn và toàn vẹn dữ liệu: lớp này chỉ có một

giao thức là SSL Record Protocol

2 Các giao thức thiết kế để thiết lập kết nối SSL: lớp này gồm có 3 giao

thức: SSL Handshake Protocol, SSL ChangeCipherSpecProtocol và SSL Alert Protocol

- SSL sử dụng các giao thức này để thực hiện các nhiệm vụ được đề cập ở trên SSL Record Protocol chịu trách nhiệm mã hoá và đảm bảo toàn vẹn dữ liệu Như

ta thấy trong hình 2, giao thức này còn chịu trách nhiệm đóng gói các dữ liệu của các giao thức SSL khác tức là cũng liên quan đến các tác vụ kiểm tra dữ liệu SSL

Ba giao thức còn lại chịu trách nhiệm quản lý các phiên, quản lý các tham số mã hoá và truyền các thông điệp SSL giữa client và server Trước khi đi vào chi tiết

về vai trò của từng giao thức chúng ta hãy xem xét hai khái niệm mang tính nền tảng liên quan tới việc sử dụng SSL

- Để 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)

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.1 và được minh họa một phần trong hình 2 Ngày nay, "S" chỉ định việc sử dụng SSL được thêm (hậu tố) nhất quán vào các

từ ghép của các giao thức ứng dụng tương ứng (trong một số thuật ngữ ban đầu, S được sử dụng và được thêm tiền tố một cách không nhất quán và một số từ ghép)

Bảng1.1: 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.2 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.3 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.2 Các thành phần thông tin trạng thái Session SSL

Bảng 1.3 Các thành phần thông tin trạng thái nối kết SSL

1.1.3.Phiên SSL và kết nối SSL

- Các khái niệm đề cập ở trên là các khái niệm cơ bản của công nghệ SSL Ngoài ra còn có rất nhiều thuộc tính khác của SSL mà chúng ta sẽ xem xét ở đây:

• connection (kết nối): là một liên kết client/server logic với những kiểu dịch vụ thích hợp SSL connection là một kết nối điểm nối điểm giữa 2 nút mạng.

• session (phiên): là một sự kết hợp giữa một client và một server xác định bằng một bộ các tham số ví dụ thuật toán sẽ sử dụng, số hiệu phiên v.v Khi một phiên SSL giữa một client và một server được thiết lập bằng giao thức SSL Handshake Protocol thì tất cả các kết nối sau này được thiết lập giữa cặp server/client đó sẽ sử dụng chung bộ tham số đó mà không phải tiến hành thoả thuận lại Điều đó có nghĩa là trong một phiên SSL giữa một client và một server

có thể có nhiều kết nối giữa client và server đó Về lý thuyết cũng có thể có nhiều phiên SSL dùng chung một kết nối, nhưng trên thực tế không sử dụng đến khả năng này Khái niệm phiên và kết nối SSL liên quan đến nhiều tham số sử dụng trong truyền thông hỗ trợ SSL giữa client và server Trong quá trình thoả thuận của giao thức handshake ngoài việc chọn các phương pháp mã hoá dữ liệu thì một loạt các tham số của Session State cũng được chọn, Session State bao gồm:

 Session identifier: là định danh do server tạo ra và gán cho mỗi phiên làm việc với một client nhất định,

 Peer certificate: chứng chỉ X.509 của nút còn lại của phiên,

 Phương pháp nén: xác định phương pháp nén dữ liệu trước khi mã hoá,

 Mô tả thuật toán CipherSpec: xác định thuật toán để mã hoá dữ liệu (ví dụ thuật toán DES) và thuật toán băm dữ liệu (ví dụ MD5)

 Số ngẫu nhiên của Server và client: dữ liệu ngẫu nhiên do cả client

và server sinh ra cho mỗi kết nối,

 Server write MAC secret: chìa khoá bí mật do server sử dụng để mã hoá dữ liệu của server,

 Client write MAC secret: chìa khoá bí mật do client sử dụng để mã hoá dữ liệu của client.

 Server write key: chìa khoá mà server dùng để mã hoá và client dùng để giải mã dữ liệu

 Client write key: chìa khoá mà client dùng để mã hoá và server dùng để giải mã dữ liệu

 Sequence number (số thứ tự): server và client quản lý một cách riêng rẽ các số thứ tự để đánh số các thông điệp gửi và nhận cho mỗi kết nối

1.4.SSL Record Protocol

- SSL Record Protocol sử dụng để trao đổi tất cả các kiểu dữ liệu trong một phiên – bao gồm các thông điệp, dữ liệu của các giao thức SSL khác và dữ liệu của ứng dụng

- SSL Record Protocol liên quan đến việc bảo mật và đảm bảo toàn vẹn dữ liệu Mục đích của SSR Record Protocol là thu nhận những thông điệp mà ứng dụng chuẩn bị gửi, phân mảnh dữ liệu cần truyền, đóng gói, bổ xung header tạo thành một đối tượng gọi là bản ghi (record), bản ghi đó được mã hoá và có thể truyền bằng giao thức TCP

- Bước đầu tiên của quá trình chuẩn bị truyền dữ liệu là phân mảnh dữ liệu, tức là chia nhỏ dòng dữ liệu thành các mảnh kích thước 16KB (hoặc nhỏ hơn) Những mảnh dữ liệu này sau đó có thể được nén trước khi truyền Sau đó bắt đầu quá trình tạo các bản ghi cho mỗi đơn vị dữ liệu bằng cách bổ xung thêm header, một

số byte cho đủ kích thước qui định của bản ghi nếu kích thước bản ghi chưa đủ và cuối cùng là phần MAC MAC (Message Authentication Code) là mã xác thực thông điệp sử dụng để khi phát dữ liệu trong các phiên SSL

- Phần header của mỗi bản ghi chứa 2 thông tin quan trọng đó là độ dài của bản ghi

và độ dài của khối dữ liệu thêm vào phần dữ liệu gốc Phần dữ liệu của một bản ghi gồm:

• dữ liệu gốc,các byte bổ xung cho đủ kích thước gói tin qui định,giá trị MAC

- MAC được sử dụng để kiểm chứng sự toàn vẹn của thông điệp chứa trong bản ghi gửi cùng với MAC đó MAC là kết quả của một của một hàm băm theo một thuật toán băm được qui địng trước (ví dụ MD5 hoặc SHA-1)

- MAC được tính toán dựa trên việc áp dụng hàm băm trên các dữ liệu sau: khoá bí mật, dữ liệu gốc, phần thông tin bổ xung, số thứ tự

- Khoá bí mật ở đây có thể là khoá ghi MAC của client (client write MAC secret) hoặc của server (server write MAC secret) tuỳ thuộc vào ai là người tạo gói tin

- Sau khi nhận được một gói tin thì bên nhận tự tính lại giá trị MAC và so sánh với giá trị MAC chứa trong gói tin đó Nếu hai giá trị MAC đó giống nhau có nghĩa là

dữ liệu không bị thay đổi trong quá trình truyền trên mạng Độ dài của trường MAC phụ thuộc vào phương pháp để tính ra nó

- Tiếp theo, phần dữ liệu cộng với MAC sẽ được mã hoá sử dụng phương pháp mã hoá (đối xứng) đã thoả thuận trước ví dụ DES hoặc triple DES Như vậy là cả dữ liệu và MAC đều được mã Phần dữ liệu đã được mã hoá đó được gắn thêm header bao gồm các trường sau:

 Kiểu nội dung (content type): xác định dữ liệu nào chứa trong gói tin để quyết định xem giao thức nào ở lớp cao hơn sẽ chịu trách nhiệm xử lý dữ liệu của gói tin đó Các giá trị có thể của trường này là: change_cipher_spec, alert, handshake

và application_data tham chiếu đến các giao thức tương ứng ở mức cao hơn

 Phiên bản chính (major version): phần chỉ số chính của phiên bản SSL đang sử dụng.Ví dụ với SSL 3.0 thì giá trị trường này là 3

 Phiên bản phụ (minor version): phần chỉ số phụ của phiên bản SSL đang sử dụng

Ví dụ với SSL 3.0 thì giá trị trường này là 0

- Sau khi tính toán xong các trường này, bản ghi đã được tạo xong và sẵn sàng để gửi đến cho máy đích Toàn bộ quá trình chuẩn bị bản ghi trước khi gửi được mô

tả trong hình 1.3

Hình 1.3: Quá trình tạo một bản ghi của SSL Record Protocol

1.1.5.Alert Protocol

- Alert Protocol được các bên sử dụng để mang các thông điệp của phiên liên quan

tới việc trao đổi dữ liệu và hoạt động của các giao thức Mỗi thông điệp của giao thức này gồm 2 byte Byte thứ nhất chứa một trong hai giá trị là warning (1) và fatal (2) xác định tính nghiêm trọng của thông điệp Khi một trong 2 bên gửi thông điệp có giá trị bít đầu tiên là fatal (2) thì phiên làm việc giữa 2 bên sẽ kết thúc ngay lập tức Byte tiếp theo của thông điệp chứa mã lỗi xảy ra trong phiên giao dịch SSL

1.1.6.Change CipherSpec Protocol

- Đây là giao thức SSL đơn giản nhất Nó chỉ chứa một thông điệp mang giá trị 1

Mục đích duy nhất của thông điệp này là làm chuyển trạng thái của một phiên từ

“đang chờ” (pending) sang “bền vững” (fixed) Ví dụ khi 2 bên qui ước bộ giao thức nào sẽ sử dụng Cả client và server đều phải gửi thông điệp loại này cho bên đối tác, sau khi đã trao đổi xong thì coi như hai bên đã đồng ý với nhau

1.1.7.Handshake Protocol

- SSL Handshake Protocol là giao thức con SSL chính được xếp lớp trên SSL

Record Protocol.Kết quả, các thông báo thiết lập quan hệ SSL được cung cấp cho lớp bản ghi SSL nơi chúng được bao bọc trong một hoặc nhiều bản ghi SSL vốn được xử lý và được chuyển như được xác định bởi phương pháp nén và thông số mật mã của session SSL hiện hành và các khóa mật mã của nối kết SSL tương ứng Mục đích của SSL Handshake Protocol là yêu cầu một client và server thiết lập và duy trì thông tin trạng thái vốn được sử dụng để bảo vệ các cuộc liên lạc

Cụ thể hơn, giao thức phải yêu cầu client và server chấp thuận một 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 ý):

số bảo mật của một nối kết hiện có Thông báo CLIENTHELLO bao gồm các trường sau đây:

 Số của phiên bản SSL cao nhất được biểu hiện bởi client (thường là 3.0).

 Một cấu trúc ngẫu nhiên do client tạo ra gồm một tem thời gian 32 bit có dạng UNIX chuẩn và một giá trị 28 byte được tạo ra bởi một bộ tạo số giả ngẫu nhiên

 Một định danh session mà client muốn sử dụng cho nối kết này

 Một danh sách các bộ mật mã client hỗ trợ

 Một danh sách các phương pháp nén mà client hỗ trợ

- Chú ý rằng trường session identity (định danh session) nên rỗng nếu session SSL hiện không tồn tại hoặc nếu client muốn tạo các tham số bảo mật mới Ở một trong hai trường hợp, một trường session identity không rỗng là xác định một session SSL hiện có giữa client và server (nghĩa là một session có các tham số bảo mật mà client muốn sử dụng lại.) Định danh session có thể bắt nguồn từ một nối kết trước đó, nối kết này hoặc một nối kết đang hoạt động Cũng chú ý rằng danh sách các bộ mật mã được hỗ trợ, được chuyển từ client đến server trong thông báo CLIENTHELLO, chứa các tổ hợp thuật toán mật mã được hỗ trợ bởi client theo thứ tự ưu tiêm Mỗi bộ mật mã xác định một thuật toán trao đổi khóa và một thông báo mật mã Server sẽ chọn một bộ mật mã hoặc nếu các lựa chọn có thể chấp nhận được không được trình bầy, trả về một thông báo lỗi và đóng nối kết một cách phù hợp Sau khi đã gởi thông báo CLIENTHELLO, client đợi một thông báo SERVERHELLO Bất kỳ thông báo khác được trả về bởi server ngoại trừ một thông báo HELLOREQUEST được xem như là một lỗi vào thời điểm này

- Ở bước 2, server xử lý thông báo CLIENTHELLO và đáp ứng bằng một thông

báo lỗi hoặc thông báo SERVERHELLO.Tương tự như thông báo CLIENTHELLO, thông báo SERVERHELLO có các trường sau đây:

- Một số phiên bản server chứa phiên bản thấp hơn của phiên bản được đề

nghị bởi client trong thông báo CLIENTHELLO và được hỗ trợ cao nhất bởi Server

- Một cấu trúc ngẫu nhiên do server tạo ra cũng gồm một tem thời gian 32bit có

dạng UNIX chuẩn và một giá trị 28bit được tạo ra bởi một bộ tạo số ngẫu nhiên

- Một định danh session tương ứng với nối kết này

- Một bộ mật mã được chọn từ bởi server từ danh sách các bộ mật mã được hỗ trợ

bởi client

- Một phương pháp nén được chọn bởi server từ danh sách các thuật toán nén được

hỗ trợ bởi client

- Nếu định danh session trong thông báo CLIENTHELLO không rỗng, server tìm

trong cache session của nó nhằm tìm ra một mục tương hợp Nếu mục tương hợp được tìm thấy và server muốn thiết lập nối kết mới bằng cách sử dụng trạng thái session tương ứng, server đáp ứng bằng cùng một giá trị như được cung cấp bởi

client Chỉ địn này là một session được tiếp tục lại và xác định rằng cả hai phía phải tiến hành trực tiếp với các thông báo CHANGECIPHERSPEC và FINISHED được trình bày thêm bên dưới Nếu không, trường này chứa một giá trị khác nhận biết một session mới Server cũng có thể trả về một trường định danh session rỗng để biểu thị rằng session sẽ không được lưu trữ và do đó không thể được tiếp tục sau đó Cũng chú ý rằng trong thông báo SERVERHELLO,server chọn một bộ mật mã và một phương pháp nén từ các danh sách được cung cấp bởi client trong thông báo CLIENTHELLO Các thuật toán trao đổi khóa, xác thực, mã hóa và xác thực thông báo được xác định bởi bộ mã được chọn bởi server và được làm lộ ra trong thông báo SERVERHELLO Các bộ mật mã vốn đã được xác định trong giao thức SSL về

cơ bản giống như bộ mật mã đã xác định cho TLS (như được tóm tắt ở các bản 1.4 đến 1.7 trong những bài viết trước)

- Ngoài thông báo SERVERHELLO, server cũng phải gởi các thông báo khác đến

client Ví dụ, nếu server sử dụng sự xác thức dựa vào chứng nhân, server gởi chứng nhận site của nó đến client trong một thông báo CERTIFICATE tương ứng Chứng nhận phải thích hợp cho thuật toán trao đổi khóa của bộ mật mã được chọn và thường là một chứng nhận X.509v3 Cùng loại thông báo sẽ được sử dụng sau đó cho sự đáp ứng của client đối với thông báo sẽ được sử dụng sau đó cho sự đáp ứng của client đối với thông báo CERTIFICATERequest của server Trong trường hợp của các chứng nhận X.509v3, một chứng nhận có thể thực sự tham chiếu đến toàn bộ một chuỗi các chứng nhận, được sắp xếp theo thứ tự với chứng nhận của đối tượng gởi trước tiên theo sau là bất kỳ chứng nhận CA tiến hành theo trình tự hướng đến một CA gốc (vốn sẽ được chấp nhận bởi client)

- Tiếp theo, server có thể gởi một thông báo SERVERKEYEXCHANGE đến

client nếu nó không có chứng nhận, một chứng nhận vốn có thể được sử dụng chỉ để xác nhận các chữ ký kỹ thuật số hoặc sử dụng thuật toán trao đổi khóa dựa vào token FORITEZZA (KEA) Rõ ràng, thông báo này không được yêu cầu nếu chứng nhận site gồm một khóa chung RSA vốn có thể được sử dụng trong việc

mã hóa Ngoài ra, một server không nặc danh có thể tùy ý yêu cầu một chứng nhận cá nhân để xác thực client Do đó, nó gởi một thông báo CERTIFICATERequest đến client Thông báo này chứa một danh sách các loại chứng nhận được yêu cầu, được phân loại theo thứ tự ưu tiên của server cũng như một danh sách các tên được phân biệt cho các CA có thể chấp nhận Ở cuối bước 2, server gởi một thông báo SERVERHELLODone đến client để chỉ định sự kết thúc SERVERHELLO và các thông báo đi kèm

- Sau khi nhận SERVERHELLO và các thông báo đi kèm, client xác nhận rằng

chứng nhận site server (nếu được cung cấp) là hợp lệ và kiểm tra nhằm bảo đảm rằng các thông số bảo mật được cung cấp trong thông báo SERVERHELLO có thể được chấp nhận Nếu server yêu cầu sự xác thực client, client gởi một thông báo CERTIFICATE vốn chứa một chứng nhận cá nhân cho khóa chung 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ủa client sử dụng khóa chung từ chứng nhận server cùng với một số tham số riêng trong token của client Client gởi các tham số chung cần thiết cho server để cũng tạo TEK, sử dụng các tham sô riêng của nó Nó tạo một khóa mật chính, bao bọc nó bằng cách sử dụng TEK và gởi kết quả cùng với một số vector khởi tạo đến server như là một phần của thông báo CLIENTKEYEXCHANGE Lần lượt, server có thể giải mã khóa mật chính một cách thích hợp Thuật toán trao đổi khóa này không được sử dụng rộng rãi

- Nếu sự xác thực client được yêu cầu, client cũng gởi một thông báo CERTIFICATEVERIFY đến server Thông báo này được sử dụng để cung cấp

sự xác thực rõ ràng định danh của người dùng dựa vào chứng nhận các nhân

Nó chỉ được gởi theo sau một chứng chỉ client vốn có khả năng tạo chữ ký (tất cả chứng nhận ngoại trừ các chứng nhận chứa các tham số DiffeHallman cố định) Sau cùng, client hoàn tất bước 3 bằng cách gởi một thông báo CHANGECIPHERSPEC và một thông báo FINISHED tương ứng đến server Thông báo FINISHED luôn được gởi ngay lập tức sau thông báo CHANGECIPERSPEC để xác nhận rằng các tiến trình trao đổi khóa và xác thực

đã thành công Thực tế, thông báo FINISHED là thông báo đầu tiên vốn được bảo

vệ bằng các thuật toán mới được thương lượng và các khóa session Nó chỉ có thể được tạo và được xác nhận nếu những khóa này được cài đặt một cách phù hợp ở

cả hai phía Không đòi hỏi sự báo nhận thông báo FINISHED; các phía có thể bắt đầu gởi dữ liệu được mã hóa ngay lập tức sau khi đã gởi thông báo FINISHED Việc thực thi SSL Handshake Protocol hoàn tất bằng việc cũng yêu cầu server gởi một thông báo CHANGECIPHERSPEC và một thông báo FINISHED tương ứng đến client ở bước 4

- Sau khi sự thiết lập SSL hoàn tất, một nối kết an toàn được thiết lập giữa client và

server Nối kết này bây giờ có thể được sử dụng để gởi dữ liệu ứng dụng vốn được bao bọc bởi SSL Record Protocol Chính xác hơn, dữ liệu ứng dụng có thể được phân đoạn, được nén, hoặc được mã hóa và đước xác thực theo SSL Record Protocol cũng như thông tin trạng thái session và nối kết vốn bây giờ được thiết lập (tùy thuộc việc thực thi SSL Handshake Protocol)

- SSL Handshake Protocol có thể được rutst ngắn nếu client và server quyết định

tiếp tục lại một session SSL được thiết lập trước đó (và vẫn được lưu trữ) hoặc lặp lại một session SSL hiện có Trong trường hợp này, chỉ ba dòng thông báo

và tổng cộng sáu thông báo được yêu cầu Các dòng thông báo tương ứng có thể được tóm tắt như sau:

- Ở 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

1.1.8.Phân tích bảo mật

- Sự phân tích bảo mật toàn diện về SSL 3.0 đã được thực hiện bởi Bruce Scheneier và David Wagner vào năm 1996 Ngoại trừ một số khiếm khuyết nhỏ

và những tính năng gây lo lắng vốn có thể được sữa chữa dễ dàng mà không cần

tu sửa cấu trúc cơ bản của giao thức SSL, họ không tìm thấy vấn đề điểm yếu hoặc bảo mật nghiêm trọng trong việc phân tích của họ Kết quả, họ kết luận rằng giao thức SSL cung cấp sự bảo mật hoàn hảo ngăn việc nghe lén và những cuộc tấn công thụ động khác, và người thực thi giao thức này sẽ ý thức đến một số cuộc tấn công chủ động tinh vi

- Tuy nhiên, một vài tháng sau, Daniel Bleichenbacher từ Bell Laboratoires đã tìm thấy một cuộc tấn công text mật mã được chọn thích ứng nhắm các giao thức dựa vào tiêu chuẩn mà khóa chung (PKCS) #1 Cuộc tấn công đã được xuất bản vào năm 1998 Tóm lại, một hoạt động khóa riêng RSA (một hoạt động giải mã hoặc chữ ký kỹ thuật số có thể được thực hiện nếu kẻ tấn công truy cập một oracle mà đối với bất kỳ text mật mã được chon, trả về chỉ 1 bit cho biết text mật mã có tương ứng với một số khối dữ liệu không được biết được mã hóa bằng cách sử dụng PKCS #1 hay không.)

- Để tìm hiểu cuộc tấn công Bleichenbacher, cần phải xem PKCS #1 Thực tế, có

ba dạng khối được xác định trong PKCS #1: các loại khối 0 và 1 được sử dụng cho các chữ ký kỹ thuật số RSA và loại khối 2 được sử dụng cho việc mã hóa RSA Các phần thảo luận trước, hãy nhớ rằng nếu thuật toán RSA được sử dụng cho việc xác thực server và trao đổi khóa, client tạo ngẫu nhiên một khóa mật chính 46 byte, thêm tiền tố hai byte 03 (số phiên bản giao thức SSL) và 00 vào khóa mật chính, mã hóa kết quả bằng cách sử dụng khóa chung của server và

gởi nó trong một thông báo CLIENTKEYEXCHANGE đến server Do đó, thông báo CLIENTkEYEXCHANGE mang khóa mật chính được mã hóa phải phù hợp với dạng được xác định trong loại khóa 2 PKCS #1.

- Bây giờ giả sử có một kẻ tấn công có thể gửi một số tùy ý của các thông báo ngẫu nhiên đến một server SSL và server đáp ứng cho từng thông báo này bằng 1 bit chỉ định xem một thông báo cụ thể có được mã hóa chính xác và được mã hóa theo PKCL #1 (do đó server có chức năng như một oracle hay không) Với sự giả định này, Bleichenbacher đã phát triển một cuộc tấn công để thực hiện một hoạt động RSA một cách bất hợp pháp với khóa riêng của server (với một hoạt động giải hoặc một chữ ký kỹ thuật số) Khi được áp dụng để giải mã một khóa mật chính của thông báo CLIENTKEYEXCHANGE được gửi trước đó, kẻ tấn công

có thể tạo lại khóa mật chính và khóa session vốn được dẫn xuất từ nó một cách phù hợp Kết quả, sau đó kẻ tấn công có thể giải mã toàn bộ session (nếu người này đã giám sát và lưu trữ dòng dữ liệu của session đó)

- Nếu cuộc tấn công có sức chú ý về mặt lý thuyết Chú ý rằng kết quả thử nghiệm

đã cho thấy thường giữa 300.000 và 2 triệu text mật mã được chọn được yêu cầu

để thực sự thực hiện hoạt động (giải mã hoặc chữ ký kỹ thuật số) Để làm cho mọi thứ trở nên tệ hơn, cuộc tấn công có thể được thực hiện trên một server SSL vốn có sẵn on-line (vì nó phải hoạt động như một oracle) Từ quan điểm của kẻ tấn công, có thể khó gửi số lượng lớn text mật mã được chọn này đến server SSL

mà không làm cho nhà quản trị server trở lên nghi ngờ

- Có một số khả năng để ngăn ngừa sự tấn công Bleichenbacher Trên hết, server không cần đáp ứng lại một thông báo lỗi sau khi đã nhận một thông báo CLIENTKEYEXCHANGE vốn không phù hợp với PKCS #1 Một khả năng khác

là thay đổi dạng khối PKCS #1 để mã hóa và loại bỏ các byte 00 và 02 dẫn đầu cũng như các byte 00, 03 và 00 ở giữa thông báo (như được minh họa trong hình 6.3) Sau cùng, một khả năng khác là sử dụng các sơ đồ mã hóa có khả năng nhận biết text thuần túy chẳng hạn như các sơ đồ được đề xuất bởi Mihir Bellar và Philip Rogaway và bất kỳ hệ thống mật mã khóa chng khác vốn có thể bảo vệ ngăn ngừa các cuộc tấn công text mật mã được chọn thích ứng

và hướng dẫn nó tìm đúng trang Web được yêu cầu và kéo về mở trên trình duyệt Web Nói nôm na hơn, HTTP là giao thức truyền tải các file từ một Web server vào một trình duyệt Web để người dùng có thể xem một trang Web đang hiện diện trên Internet.HTTP là một giao thức ứng dụng của bộ giao thức TCP/IP (các giao thức nền tảng cho Internet).

HTTPS là gì?

- HTTPS( Secure HTTP), là một sự kết hợp giữa giao thức HTTP và giao thức bảo

mật SSL hay TLS cho phép trao đổi thông tin một cách bảo mật trên Internet Các kết nối HTTPS thường được sử dụng cho các giao dịch thanh toán trên World Wide Web và cho các giao dịch nhạy cảm trong các hệ thống thông tin công ty HTTPS được sử dụng trong nhiều tình huống, chẳng hạn như các trang đăng nhập cho ngân hàng, các hình thức, ích đăng nhập công ty, và các ứng dụng khác, trong

đó dữ liệu cần phải được an toàn.HTTPS không nên nhầm lẫn với Secure HTTP (S-HTTP) quy định trong RFC 2660

1.2.2.Phân tích hoạt động của giao thức HTTPS

- Giao thức HTTPS sử dụng port 443, và cung cấp các dịch vụ hay đảm bảo tính

chất sau của thông tin:

Confidentiality: sử dụng phương thức encryption để đảm bảo rằng các thông

điệp được trao đổi giữa client và server không bị kẻ khác đọc được

Integrity: sử dụng phương thức hashing để cả client và server đều có thể tin

tưởng rằng thông điệp mà chúng nhận được có không bị mất mát hay chỉnh sửa

Authenticity: sử dụng digital certificate để giúp client có thể tin tưởng rằng

server/website mà họ đang truy cập thực sự là server/website mà họ mong muốn vào, chứ không phải bị giả mạo

1.2.2.1 Sử dụng HTTPS như thế nào?

- Trước hết, muốn áp dụng HTTPS thì trong quá trình cấu hình Webserver, có thể

dễ dàng tự tạo ra một SSL certificate dành riêng cho website của mình và nó được

gọi là self-signed SSL certificate.

SSL certificate tự cấp này vẫn mang lại tính Confidentiality và Integrity cho quá trình truyền thông giữa server và client Nhưng rõ ràng là không đạt được

tính Authenticity bởi vì không có bên thứ 3 đáng tin cậy nào (hay CA) đứng ra

kiểm chứng sự tính xác thực của certificate tự gán này Điều này cũng giống như việc một người tự làm chứng minh nhân dân (CMND) cho mình rồi tự họ ký tên, đóng dấu luôn vậy!

Vì vậy, đối với các website quan trọng như E-Commerce, Online Payment, Web Mail,… thì họ sẽ mua một SSL certificate từ một Trusted Root CA nổi tiếng như VeriSign, Thawte, và ít tên tuổi hơn thì có GoDaddy, DynDNS… Các CA có 2 nhiệm vụ chính sau:

- Cấp phát và quản lý SSL certificate cho server/website

- Xác thực sự tồn tại và tính hiệu lực của SSL certificate mà Web client gửi tới cho nó

Thực chất thì SSL certificate cũng là một loại digitial certificate (một loại file trên máy tính) Vì giao thức HTTPS có dính tới giao thức SSL nên người ta mới đặt tên cho nó là SSL certificate để phân biệt với các loại digital certificate khác

như Personal Certificate, Server Certificate, Software Publisher Certificate,

Certificate Authority Certificate.

Dưới đây là một số thông tin quan trọng được chứa trong SSL certificate mà bất

cứ client nào cũng có thể xem được bằng cách click vào biểu tượng padlock trên thanh Address của Web browser:

- Thông tin về owner của certificate (như tên tổ chức, tên cá nhân hoặc domain của website…)

- Tên và digital signature của CA cấp certificate

- Khoảng thời gian mà certificate còn hiệu lực sử dụng

- Public key của server/website Còn private key được lưu trữ trên chính server (không có trong certificate) và tuyệt đối không thể để lộ cho bất cứ client nào

- Một số thông tin phụ khác như: loại SSL certificate, các thuật toán dùng để encryption và hashing, chiều dài (tính bằng bit) của key, cơ chế trao đổi key (như

RSA, DSA…).

1.2.2.2.Quá trình giao tiếp giữa client và server thông qua HTTPS

1 Client gửi request cho một secure page (có URL bắt đầu với https://)

2 Server gửi lại cho client certificate của nó

3 Client gửi certificate này tới CA (mà được ghi trong certificate) để kiểm chứng

Giả sử certificate đã được xác thực và còn hạn sử dụng hoặc client vẫn cố tình truy cập mặc dù Web browser đã cảnh báo rằng không thể tin cậy được

certificate này (do là dạng self-signed SSL certificate hoặc certificate hết hiệu lực, thông tin trong certificate không đúng…) thì mới xảy ra bước 4 sau

4 Client tự tạo ra ngẫu nhiên một symmetric encryption key, rồi sử dụng public

key (trong certificate) để mã hóa symmetric key này và gửi về cho server.

5 Server sử dụng private key (tương ứng với public key trong certificate ở trên)

để giải mã ra symmetric key ở trên

6 Sau đó, cả server và client đều sử dụng symmetric key đó để mã hóa/giải mã các thông điệp trong suốt phiên truyền thông

Và tất nhiên, các symmetric key sẽ được tạo ra ngẫu nhiên và có thể khác nhau trong mỗi phiên làm việc với server Ngoài encryption thì cơ chế hashing

sẽ được sử dụng để đảm bảo tính Integrity cho các thông điệp được trao đổi

1.2.3 SMTPS

1.2.3.1 Giao thức SMTP và SMTPS

SMTP là gì?

- SMTP (tiếng Anh: Simple Mail Transfer Protocol - giao thức truyền tải

thư tín đơn giản) là một chuẩn truyền tải thư điện tử qua mạng Internet SMTP được định nghĩa trong bản RFC 821 (STD 10) và được chỉnh lý bằng bản RFC 1123 (STD 3) Giao thức hiện dùng được là ESMTP (extended SMTP - SMTP mở rộng), được định nghĩa trong bản RFC 2821

Lịch sử

o SMTP là một giao thức dùng nền văn bản và tương đối đơn giản Trước khi một thông điệp được gửi, người ta có thể định vị một hoặc nhiều địa chỉ nhận cho thông điệp - những địa chỉ này thường được kiểm tra về sự tồn tại trung thực của chúng) Việc kiểm thử một trình chủ SMTP là một việc tương đối dễ dàng, dùng chương trình ứng dụng "telnet

o SMTP dùng cổng 25 của giao thức TCP Để xác định trình chủ SMTP của một tên miền nào đấy (domain name), người ta dùng một mẫu tin MX (Mail eXchange - Trao đổi thư) của DNS (Domain Name System - Hệ thống tên miền)

o SMTP bắt đầu được sử dụng rộng rãi vào những năm đầu thập niên kỷ

1980 Tại thời điểm đó, SMTP chỉ là một phần mềm bổ sung của bộ trình ứng dụng đồng giao thức UUCP (Unix to Unix CoPy - Sao chép từ máy Unix sang máy Unix)nhưng tiện lợi hơn trong việc truyền tải thư điện tử giữa các máy vi tính - những máy này thỉnh thoảng mới lại được kết nối với nhau một lần, để truyền thông dữ liệu Thực ra, SMTP sẽ làm việc tốt hơn nếu các máy gửi và máy nhận được kết nối liên tục.Sendmail là một trong những phần mềm đặc vụ truyền tải thư tín (mail transfer agent) đầu tiên (nếu không phải là cái trước tiên nhất) thực thi giao thức SMTP Tính đến năm 2001, người ta đã thấy có ít nhất là 50 chương trình ứng dụng thực thi giao thức SMTP, bao gồm cả trình khách (phần mềm dùng để gửi thông điệp) và trình chủ (phần mềm dùng để nhận thông điệp) Một số trình chủ SMTP nổi tiếng có thể liệt kê bao gồm: exim, Postfix, qmail, và Microsoft Exchange Server

o Do thiết kế của giao thức dùng dạng thức văn bản thường của bộ mã ASCII, khi bản thiết kế được khởi công, chức năng của SMTP giải quyết tập tin có dạng thức nhi phân rất kém Những tiêu chuẩn như MIME đã được xây dựng để mã hóa những tập tin nhị phân, cho phép chúng được truyền tải dùng giao thức SMTP Hiện nay, phần lớn các trình chủ SMTP

hỗ trở phần mở rộng 8BITMIME của SMTP, cho phép các tập tin ở dạng thức nhị phân được truyền thông qua đường dây, dễ như việc truyền tải văn bản thường vậy

o SMTP là một giao thức "đẩy" thông điệp và không cho phép ai "rút" thông điệp từ máy chủ ở xa, theo yêu cầu của mình, một cách tùy tiện Để lấy được thông điệp, một trình khách thư điện tử phải dùng POP3 (Post Office Protocol - Giao thức bưu điện tử) hoặc IMAP (Internet Message Access Protocol - Giao thức truy cập thông điệp Internet) Chúng ta còn có thể dùng phần mềm ETRN (Extended Turn) để khởi động một trình chủ SMTP phân phát thông điệp mà nó đang lưu trữ.

Ví dụ về truyền thông của SMTP

o Sau khi kết nối giữa người gửi (trình khách) và người nhận (trình chủ) đã được thiết lập, những việc làm sau đây là những việc hoàn toàn hợp lệ, đối với một phiên giao dịch dùng giao thức SMTP Trong cuộc hội thoại dưới đây, những gì trình khách gửi được đánh dấu bằng chữ C: đứng trước, còn những gì trình chủ gửi được đánh dấu bằng S: Các hệ thống máy tính đều

có thể thiết lập một kết nối, bằng cách dùng những dòng lệnh của phần mềm telnet, trên một máy khách

o Chẳng hạn:

telnet www.example.com 25 khởi động một kết nối SMTP từ máy gửi thông điệp đến máy chủ site

1.2.3.2.Cấu trúc cơ bản của SMTP

- Thiết kế SMTP có thể được hình như:

+ -+ + -+

+ -+ | | | |

| User |< >| | SMTP | |+ -+ | Khách hàng | Commands / Trả lời | Server |+ -+ | SMTP |< ->| SMTP | + -+

| File |< >| | Mail | |< >| File |

| Hệ thống | | | | | | Hệ thống |+ -+ + -+ + -+ + -+

Máy chủ SMTP SMTP khách hàng

- Khi một khách hàng SMTP có một thông điệp để truyền tải, thiết lập một cách kênh truyền đến một máy chủ SMTP Trách nhiệm của một SMTP khách hàng là chuyển các tin nhắn mail cho một hoặc nhiều máy chủ SMTP

1.2.3.3.Cơ chế mở rộng của SMTP

- SMTP hiện tại phải hỗ trợ phần mở rộng cơ bản cơ chế Ví dụ, máy chủ phải hỗ trợ lệnh EHLO nếu họ không thực hiện bất kỳ phần mở rộng cụ thể và khách hàng NÊN ưu tiên sử dụng EHLO thay vì hơn HELO (Tuy nhiên, đối khả năng tương thích với cũ triển khai phù hợp, SMTP khách hàng và các máy chủ phải hỗ trợ HELO cơ chế ban đầu như một dự phòng.)

- Khung mở rộng bao gồm:

+ SMTP lệnh EHLO, thay thế HELO trước đó,+ Một đăng ký phần mở rộng dịch vụ SMTP,+ Thêm các thông số SMTP MAIL và lệnh RCPT, và tùy chọn thay thế cho các lệnh quy định, như cho dữ liệu được truyền đi trong không ASCII

1.2.3.4.Các thủ tục trong SMTP

- Khởi tạo phiên : Một phiên SMTP là bắt đầu khi một khách hàng sẽ mở ra một kết nối tới một máy chủ và máy chủ đáp ứng với một thông báo mở đầu

- Khởi tạo user : Một khi máy chủ đã gửi tin nhắn chào đón và khách hàng có nhận được nó, khách hàng thường gửi lệnh EHLO

- Send mail :

+Bước đầu tiên trong thủ tục là lệnh MAIL

MAIL FROM: <reverse-path> [SP <mail-parameters>] <CRLF>

Lệnh này cho SMTP-nhận một giao dịch thư mới bắt đầu và thiết lập lại tất cả các bảng nhà nước và bộ đệm của nó, bao gồm bất kỳ người nhận hoặc dữ liệu thư

+Bước thứ hai trong thủ tục là lệnh RCPT

RCPT: <forward-path> [SP <rcpt-parameters>] <CRLF>

+ Bước thứ ba trong các thủ tục là lệnh dữ liệu (hoặc một số

DATA <CRLF>

1.2.4.POPS

1.2.4.1.Giao thức POP3 và POPS

POP3

- Trong máy tính, Post Office Protocol (POP) là một giao thức lớp ứng dụng Internet tiêu chuẩn được sử dụng bởi khách hàng địa phương e-mail để lấy e-mail

từ một máy chủ từ xa trên một kết nối TCP / IP [1] POP và IMAP (Internet Message Access Protocol) là hai tiêu chuẩn giao thức Internet phổ biến nhất cho e-mail [2] Hầu như tất cả các e-mail khách hàng hiện đại và máy chủ hỗ trợ cả hai Các giao thức POP đã được phát triển thông qua một số phiên bản, với phiên bản 3 (POP3) là tiêu chuẩn hiện hành Giống như IMAP, POP3 được hỗ trợ bởi hầu hết các dịch vụ webmail như Hotmail, Gmail và Yahoo! Mail.Contents

- Post Office Protocol phiên bản 3 (POP3) là một giao thức tầng ứng dụng, dùng để lấy thư điện tử từ server mail, thông qua kết nối TCP/IP POP3 và IMAP4 (Internet Message Access Protocol) là 2 chuẩn giao thức Internet thông dụng nhất dùng để lấy nhận email Hầu như các máy tính hiện nay đều hỗ trợ cả 2 giao thức

- Trước POP3, đã có 2 phiên bản là POP1 và POP2 Khi POP3 ra đời, đã ngay lập tức thay thế hoàn toàn các phiên bản cũ Vì vậy, ngày nay, nhắc đến POP thì thường là ám chỉ POP3

- Thiết kế của POP3 hỗ trợ chức năng cho người dùng có kết nối internet không thường trực (như kết nối dial-up), cho phép người dùng kết nối với server, tải mail về, sau đó có thể xem, thao tác với mail offline Mặc dù trong giao thức hỗ trợ leave mail on server (để nguyên mail trên server), nhưng hầu hết người dùng đều thực hiện mặc định, tức là: kết nối, tải mail về, xóa mail trên server rồi ngắt kết nối

1.2.4.2.Tổng quan

- POP hỗ trợ đơn giản tải về, và xóa các yêu cầu để truy cập hộp thư từ xa (gọi là maildrop trong các RFC POP ) Mặc dù hầu hết khách hàng POP có tính để để lại thư trên máy chủ sau khi tải về, e-mail khách hàng sử dụng POP thường kết nối, lấy tất cả các tin nhắn, lưu trữ chúng trên máy tính của người sử dụng như tin nhắn mới, xóa chúng từ máy chủ, và sau đó ngắt kết nối Các giao thức khác, đặc biệt là IMAP (Internet Message Access Protocol) cung cấp truy cập từ xa hoàn chỉnh hơn và phức tạp để hoạt động hộp thư điển hình Nhiều khách hàng e-mail

hỗ trợ POP và IMAP để lấy các tin nhắn, tuy nhiên, ít nhà cung cấp dịch vụ Internet (ISP) hỗ trợ IMAP

- Một máy chủ POP3 lắng nghe trên cổng 110 Thông tin liên lạc mã hóa cho POP3 hoặc yêu cầu sau khi giao thức bắt đầu, bằng cách sử dụng lệnh STLS, nếu được

hỗ trợ, hoặc bởi POP3S, kết nối với máy chủ bằng cách sử dụng Transport Layer Security (TLS) hoặc Secure Sockets Layer (SSL) TCP cổng 995 ( ví dụ như Google Gmail)

- Tin nhắn có sẵn cho khách hàng được cố định khi một phiên POP mở maildrop,

và được xác định bởi số nhắn tin địa phương cho rằng phiên, hoặc tùy chọn, bởi một định danh duy nhất được thông báo bởi các máy chủ POP Định danh duy

nhất này là vĩnh viễn và duy nhất để maildrop và cho phép khách hàng truy cập cùng một thông điệp trong các phiên POP khác nhau Thư được lấy ra và đánh dấu để xóa bởi số lượng tin nhắn Khi khách hàng ra khỏi phiên, các thư được đánh dấu để xóa được lấy ra từ maildrop.

1.2.4.3.Tiện ích mở rộng

- Một cơ chế mở rộng đã được đề xuất trong RFC 2449 để chứa các phần mở rộng chung cũng như công bố trong một tổ chức hỗ trợ cho các lệnh tùy chọn, chẳng hạn như TOP và UIDL RFC đã không có ý định để khuyến khích mở rộng, và tái khẳng định rằng vai trò của POP3 là để cung cấp hỗ trợ đơn giản chủ yếu là tải về

và xóa các yêu cầu xử lý hộp thư

- Các phần mở rộng được gọi là khả năng và được liệt kê theo lệnh CAPA Ngoại trừ APOP, các lệnh tùy chọn đã được bao gồm trong các thiết lập ban đầu của khả năng Theo sự dẫn đầu của ESMTP (RFC 5321), khả năng bắt đầu với một X biểu hiện khả năng của địa phương

STARTTLS

- Mở rộng STARTTLS cho phép sử dụng Transport Layer Security (TLS) hoặc Secure Sockets Layer (SSL) để được đàm phán bằng cách sử dụng lệnh STLS, trên cổng tiêu chuẩn POP3, chứ không phải là một thay thế Một số khách hàng

và máy chủ, chẳng hạn như Google Gmail, thay vì sử dụng phương pháp thay thế cổng phản đối, trong đó sử dụng cổng TCP 995 (POP3S)

SDPS

- Demon Internet được giới thiệu phần mở rộng để POP3 cho phép nhiều tài khoản trên mỗi miền, và đã trở thành được gọi là Tiêu chuẩn Dial-up POP3 Dịch vụ (SDPS) [1] Để truy cập mỗi tài khoản, tên người dùng bao gồm tên máy, như john @ tên máy hoặc john + hostname

So sánh với IMAP

- Khách hàng để lại thư trên máy chủ thường sử dụng các lệnh UIDL để có được

sự liên kết hiện tại của thông báo số tin nhắn được xác định bởi định danh duy nhất của nó Các định danh duy nhất là tùy ý, và có thể được lặp đi lặp lại nếu hộp thư chứa các tin nhắn giống hệt nhau Ngược lại, IMAP sử dụng một nhận dạng 32-bit duy nhất (UID) được giao để thông báo tăng dần (mặc dù không nhất

Trang 28

Mail Server và Web

Server theo giao thức

thiết phải liên tiếp) để khi họ nhận được Khi lấy tin nhắn mới, một yêu cầu khách hàng IMAP UIDs lớn hơn so với các UID cao nhất trong số tất cả các tin nhắn trước đây lấy, trong khi một khách hàng POP phải lấy toàn bộ bản đồ UIDL Đối với hộp thư lớn, điều này có thể yêu cầu chế biến đáng kể.

- MIME phục vụ như là tiêu chuẩn cho các file đính kèm và văn bản không ASCII trong e-mail Mặc dù không phải POP3 cũng không SMTP yêu cầu định dạng MIME-e-mail, về cơ bản tất cả các Internet không ASCII e-mail đến định dạng MIME, vì vậy khách hàng POP cũng phải hiểu và sử dụng MIME IMAP, thiết

kế, giả định dạng MIME-e-mail

Chương 2: ỨNG DỤNG SSL CHO CÁC DỊCH VỤ WEB VÀ

MAIL TRONG MẠNG NỘI BỘ

Trang 29

Mail Server và Web

2.1.Mô hình mạng

- Ban đầu máy Client sẽ truy cập vào Mail (SMTP và POP) và Web (HTTP) thông thường Sau khi triển khai giao thức bảo mật SSL thì máy Client sẽ truy cập vào

Mail SSL (SMTPS và POPS) và Web SSL (HTTPS).

2.2.Các bước thực hiện triển khai SSL

2.2.1.Bảo mật Website với SSL Certificate của Verisign.com

172.16.9.2/24

DC

Mail Server và Web

Server theo giao thức

SSL

Clien

Thực hiện

1 Tạo Request Certificate

- Logon Administrator, mở Internet Information Services (IIS) Manager,

bung Web Site, chuột phải Web Site, chọn Properties

- Hộp thoại Web Site Properties, qua tab Directory Security, chọn Server

Certificate

- Hộp thoại Welcome to the Web Server Certificate Wizard, chọn Next