Trước tiên, bạn sử dụng tác nhân người dùng thư hoặc MUA để đọc và gửi email từ thiết bị của mình (chẳng hạn như gmail hoặc ứng dụng thư trên thiết bị Apple). Các chương trình này chỉ hoạt động khi bạn đang sử dụng chúng.
Nói chung, chúng giao tiếp với một đại lý chuyển thư hoặc MTA (còn được gọi là máy chủ thư, máy chủ MX và trình trao đổi thư), phục vụ để nhận và lưu trữ email của bạn.
Email được lưu trữ từ xa cho đến khi bạn mở MUA để kiểm tra email của mình. Email được gửi bởi các đại lý chuyển phát thư (MDA), các đại lý này thường được đóng gói với MTA.
Thư từng được gửi đến máy chủ thư bằng SMTP hoặc Giao thức truyền thư đơn giản. SMTP là một giao thức giao tiếp dành cho email.
Ngay cả bây giờ, trong khi nhiều hệ thống độc quyền như Microsoft Exchange và các chương trình email trực tuyến như Gmail sử dụng các giao thức của riêng họ trong nội bộ, họ sử dụng SMTP để chuyển thư bên ngoài hệ thống của họ (ví dụ:nếu người dùng Gmail muốn gửi email đến ứng dụng khách Outlook).
Sau đó, thư sẽ được tải xuống từ máy chủ bằng Giao thức Bưu điện (POP3) POP3 là giao thức lớp ứng dụng cung cấp quyền truy cập qua mạng giao thức internet (IP) để ứng dụng người dùng liên hệ với hộp thư trên máy chủ thư. Nó có thể kết nối, truy xuất tin nhắn, lưu trữ chúng trên máy tính của khách hàng và xóa hoặc giữ lại chúng trên máy chủ.
Nó được thiết kế để có thể quản lý các kết nối internet tạm thời, chẳng hạn như quay số (vì vậy nó sẽ chỉ kết nối và truy xuất email khi được kết nối và cho phép bạn xem tin nhắn khi bạn ngoại tuyến). Điều này phổ biến hơn khi truy cập quay số phổ biến hơn.
Giờ đây, IMAP, Giao thức truy cập tin nhắn Internet, hầu như đã thay thế POP3. IMAP có thể cho phép nhiều máy khách quản lý cùng một hộp thư (vì vậy bạn có thể đọc email của mình từ máy tính để bàn, máy tính xách tay và điện thoại, v.v. và tất cả các thư của bạn sẽ ở đó, được sắp xếp theo cùng một cách).
Cuối cùng, webmail đã thay thế cả hai. Webmail cho phép bạn đăng nhập vào một trang web và nhận tin nhắn từ bất kỳ đâu hoặc bất kỳ thiết bị nào (yay!), Tuy nhiên bạn cần phải kết nối với Internet khi sử dụng nó. Nếu trang web (như gmail) là MUA của bạn, bạn không cần biết cài đặt máy chủ SMTP hoặc IMAP.
Email được bảo mật như thế nào?
Thật không may, bảo mật không thực sự được tích hợp vào các giao thức thư ngay từ đầu (giống như hầu hết các giao thức internet mới bắt đầu). Máy chủ chỉ mong đợi nhận bất kỳ tin nhắn nào từ bất kỳ ai và chuyển nó đến bất kỳ máy chủ nào khác có thể giúp định tuyến thông báo đến đích cuối cùng của nó (người nhận trong trường to:).
Không có gì đáng ngạc nhiên, điều này đã trở thành một vấn đề khi internet mở rộng từ một số chính phủ và nhóm nghiên cứu thành một thứ mà hầu hết thế giới sử dụng để làm mọi thứ về cơ bản. Rất nhanh chóng, thư rác và email lừa đảo đã trở thành (và vẫn) là một vấn đề lớn đối với tất cả mọi người.
Để đáp lại, chúng tôi đã cố gắng thực hiện một số biện pháp chung để ngăn mọi người đọc thư của người khác (mã hóa) và xác thực rằng thư thực sự đến từ người gửi có mục đích (xác thực).
Hầu hết các nơi sử dụng TLS (bảo mật lớp truyền tải, sự thay thế cho SSL, lớp cổng bảo mật), một giao thức mật mã cung cấp mã hóa khi truyền. Nó cung cấp khả năng bảo vệ khi tin nhắn đang được truyền đi, nhưng không phải khi dữ liệu ở trạng thái nghỉ, (ví dụ:được lưu trữ trên máy tính của bạn).
Điều này đảm bảo rằng một tin nhắn không bị thay đổi hoặc bị xem trộm khi nó đang di chuyển từ MTA sang MTA. Tuy nhiên, điều này không xác minh rằng tin nhắn không được sửa đổi trong chuyến đi.
Ví dụ:nếu email đi qua nhiều máy chủ thư trước khi đến đích cuối cùng, việc sử dụng TLS sẽ đảm bảo nó được mã hóa giữa các máy chủ, nhưng mỗi máy chủ có thể thay đổi nội dung thư. Để giải quyết vấn đề đó, chúng tôi đã tạo SPF, DKIM và DMARC.
SPF (Khung chính sách người gửi)
SPF cho phép chủ sở hữu miền (như google.com) thiết lập bản ghi TXT trong DNS của miền đó, cho biết máy chủ nào được phép gửi thư từ miền đó (để biết hướng dẫn về cách thực hiện việc này đối với nhiều nhà cung cấp dịch vụ lưu trữ, hãy xem phần này trang web).
Tính năng này hoạt động như thế nào?
Bản ghi này liệt kê các thiết bị (thường theo IP) được phép và có thể kết thúc bằng một trong các tùy chọn sau:
-all =Nếu kiểm tra không thành công (nguồn của email không phải là một trong các thiết bị được liệt kê) thì kết quả là HardFail. Hầu hết các hệ thống thư sẽ đánh dấu những thư này là thư rác.
? all ==Nếu kiểm tra không thành công (nguồn của email không phải là một trong những thiết bị được liệt kê) thì kết quả là trung tính. Điều này thường được sử dụng để thử nghiệm, không phải miền sản xuất.
~ all =Nếu kiểm tra không thành công (nguồn của email không phải là một trong những thiết bị được liệt kê) thì kết quả là một SoftFail. Điều này có nghĩa là thông báo này đáng ngờ, nhưng không nhất thiết là một thông báo xấu. Một số hệ thống thư sẽ đánh dấu những thư này là thư rác, nhưng hầu hết thì không.
Tiêu đề SPF có thể hữu ích cho chính các máy chủ khi chúng đang xử lý thông báo. Ví dụ:nếu một máy chủ nằm ở rìa của mạng, nó biết các tin nhắn mà nó nhận được phải đến từ các máy chủ trong bản ghi SPF của người gửi. Điều này giúp máy chủ thoát khỏi thư rác nhanh hơn. Mặc dù điều này nghe có vẻ tuyệt vời, nhưng thật không may, có một số vấn đề lớn với SPF.
- SPF không cho máy chủ thư biết phải làm gì với thư - nghĩa là thư có thể không kiểm tra được SPF và vẫn được gửi.
- Bản ghi SPF không xem xét địa chỉ 'từ' mà người dùng nhìn thấy, nó đang xem 'đường dẫn trả về'. Về cơ bản, địa chỉ này tương đương với địa chỉ trả hàng mà bạn viết trên một lá thư. Nó cho các máy chủ thư xử lý thư nơi gửi thư (và nó được lưu trữ trong tiêu đề email - về cơ bản các máy chủ thông tin kỹ thuật sử dụng để xử lý email).
Điều đó có nghĩa là tôi có thể đặt bất cứ thứ gì tôi muốn vào địa chỉ from:và nó sẽ không ảnh hưởng đến việc kiểm tra SPF. Trên thực tế, cả hai địa chỉ email đó đều có thể bị tin tặc giả mạo tương đối. Bởi vì không có mã hóa liên quan, tiêu đề SPF không thể được tin cậy hoàn toàn. - Bản ghi SPF cần được cập nhật liên tục, điều này có thể khó khăn trong các tổ chức lớn, luôn thay đổi.
- Chuyển tiếp phá vỡ SPF. Điều này là do nếu một email từ, chẳng hạn như google.com, được chuyển tiếp bởi bob@bobsburgers.com, thì người gửi trên phong bì vẫn không thay đổi (địa chỉ từ vẫn ghi là google.com). Máy chủ nhận thư nghĩ rằng nó được xác nhận là từ google.com, nhưng đến từ bobsburgers.com, vì vậy nó không kiểm tra được SPF (mặc dù thư thực sự đến từ google.com).
Để đọc thêm về SPF, hãy xem các bài báo này. Bạn có thể kiểm tra xem một miền cụ thể có các bản ghi SPF và DMARC được định cấu hình hay không tại đây.
DKIM (Thư được xác định DomainKeys)
DKIM tương tự như SPF. Nó cũng sử dụng các bản ghi TXT trong DNS của miền gửi và nó cung cấp một số xác thực của chính thông báo. Nó cố gắng cung cấp xác minh rằng các tin nhắn không bị thay đổi khi chuyển tiếp.
Tính năng này hoạt động như thế nào?
Miền gửi tạo cặp khóa công khai / riêng tư và đặt khóa công khai vào bản ghi DNS TXT của miền (nếu bạn không biết cặp khóa công khai / riêng tư là gì, hãy xem bài viết này về mật mã).
Sau đó, các máy chủ thư của miền (ở ranh giới bên ngoài - các máy chủ đang gửi thư bên ngoài miền (ví dụ:từ gmail.com đến outlook.com)) sử dụng khóa cá nhân để tạo chữ ký của toàn bộ nội dung thư, bao gồm tiêu đề.
Việc tạo chữ ký thường yêu cầu văn bản phải được băm và mã hóa (để biết thêm chi tiết về quy trình này, hãy xem bài viết này).
Máy chủ nhận thư sử dụng khóa công khai trong bản ghi DNS TXT để giải mã chữ ký, sau đó băm thư và các tiêu đề có liên quan (bất kỳ tiêu đề nào được tạo trong khi thư ở bên trong cơ sở hạ tầng của người gửi - ví dụ:nếu nhiều máy chủ gmail xử lý email trước đó đã được gửi bên ngoài đến outlook.com).
Sau đó, máy chủ sẽ kiểm tra để đảm bảo hai hàm băm khớp nhau. Nếu họ làm vậy, tin nhắn có thể không bị thay đổi (trừ khi ai đó đã xâm phạm khóa cá nhân của người gửi) và hợp pháp từ người gửi có mục đích. Nếu các hàm băm không khớp, thư không phải từ người gửi có chủ đích hoặc nó đã bị thay đổi bởi một số máy chủ khác đang chuyển tiếp hoặc cả hai.
DKIM thực hiện rất tốt một nhiệm vụ rất cụ thể - trả lời câu hỏi 'email này có bị thay đổi khi chuyển tiếp hay không từ người gửi có chủ đích?'. Tuy nhiên, đó là tất cả những gì nó làm. Nó không cho bạn biết cách đối phó với những email không đạt yêu cầu kiểm tra này, máy chủ nào có thể đã thay đổi thư hoặc những thay đổi nào đã được thực hiện.
DKIM cũng được một số ISP hoặc Nhà cung cấp dịch vụ Internet sử dụng để xác định danh tiếng miền của bạn (bạn có đang gửi nhiều thư rác không? Bạn có mức độ tương tác thấp không? Bao lâu thì email của bạn bị trả lại?).
Để đọc thêm về DKIM, hãy xem bài viết này. Bạn có thể xác thực bản ghi DKIM tại đây.
DMARC (Xác thực, báo cáo và tuân thủ thông báo dựa trên tên miền)
DMARC về cơ bản là hướng dẫn cho máy chủ thư về cách xử lý các bản ghi SPF và DKIM. Nó không thực hiện bất kỳ kiểm tra nào của riêng mình, nhưng nó cho máy chủ thư biết cách xử lý các kiểm tra mà SPF và DKIM thực hiện.
Các ISP tham gia sẽ xem xét các bản ghi DMARC đã xuất bản và sử dụng chúng để xác định cách đối phó với DKIM hoặc SPF không thành công. Vì vậy, ví dụ:một thương hiệu thường bị giả mạo có thể xuất bản bản ghi DMARC cho biết rằng nếu DKIM hoặc SPF không thành công, hãy bỏ thông báo.
Thông thường, ISP cũng sẽ gửi báo cáo về hoạt động của miền cho bạn kèm theo nguồn email và liệu nó có đạt / không đạt DKIM / SPF hay không. Điều này có nghĩa là bạn sẽ biết khi nào mọi người đang giả mạo (cố tình gửi từ) miền của bạn hoặc thay đổi tin nhắn của bạn.
Để triển khai DMARC, bạn cần tạo bản ghi DMARC, dựa trên nhu cầu của bạn (từ việc theo dõi lưu lượng email để tìm ra tất cả các nguồn email của bạn là gì đến yêu cầu các hành động được thực hiện, chẳng hạn như từ chối bất kỳ email nào không DKIM hoặc SPF). Bạn có thể tìm hiểu thêm về cách làm điều đó tại đây và tại đây.
Để đọc thêm về DMARC, hãy xem bài viết này. Bạn có thể kiểm tra xem một miền cụ thể có các bản ghi SPF và DMARC được định cấu hình hay không tại đây.
Kết thúc
Không có biện pháp bảo mật nào trong số những biện pháp bảo mật này là hoàn hảo, nhưng cùng nhau, chúng đã làm rất tốt việc giúp chúng tôi cải thiện tính bảo mật của hệ thống email trên toàn thế giới.
Càng có nhiều tổ chức áp dụng các biện pháp này (hoặc sử dụng triển khai mã nguồn mở hoặc trả tiền cho một sản phẩm) thì mọi người sẽ càng có lợi. Bảo mật được thêm vào sau khi một giao thức hoặc sản phẩm được phát triển thường đắt hơn, kém hiệu quả hơn và khó thực hiện hơn so với bảo mật được tích hợp trong sản phẩm.
Tuy nhiên, hầu hết các giao thức mà internet hiện tại dựa vào đều được thiết kế cho internet sơ khai - dành cho một nhóm nhỏ những người đam mê, nhà khoa học và thành viên chính phủ - không phải là mạng toàn cầu mà chúng tôi điều hành các tòa nhà, thiết bị thông minh, phương tiện công cộng, nhà máy hạt nhân. (!), và như thế.
Do đó, khi internet tiếp tục mở rộng, chúng ta cần tiếp tục thích ứng và phát triển các cách thức mới để bảo mật các hệ thống mà chúng ta dựa vào.