Là một công nghệ truyền thông kỹ thuật số, Email tiếp tục thống trị và phát triển về mức độ sử dụng. Trong bài đăng trước , tôi đã nhấn mạnh nhiều ưu điểm của nó nhưng cũng ám chỉ đến một số điểm yếu mà hầu hết người dùng hoàn toàn không biết.

Trong bài đăng này, chúng ta sẽ khám phá những điểm yếu này một cách chi tiết hơn và cụ thể là cách email được truyền giữa các máy chủ. Chúng tôi cũng sẽ nêu bật cách giải quyết những điểm yếu này bằng cách tăng cường áp dụng các tiện ích mở rộng đã thiết lập cho các giao thức email truyền thống (ví dụ: DANE).

Như mọi khi, bài viết này dựa trên nghiên cứu và thực hành cá nhân của tôi về chủ đề này nhưng việc chia sẻ kiến ​​thức là một sự hợp tác, vì vậy vui lòng cung cấp nhận xét hoặc phản hồi.

Giới thiệu

Để dễ hiểu, tôi sẽ nêu bật ba giai đoạn cấp cao về cách thiết lập kết nối giữa các máy chủ thư.

Khám phá máy chủ thư của người nhận , quá trình khám phá máy chủ thư nào sẽ chấp nhận thư cho một miền người nhận nhất định.

Kết nối với máy chủ thư của người nhận, sau khi đã xác định đúng máy chủ thư, quá trình kết nối với máy chủ đó và bảo mật kết nối bằng mã hóa phù hợp (còn gọi là TLS).

Xác minh rằng máy chủ thư của người nhận thực sự là đúng, chúng tôi có thể chắc chắn rằng chúng tôi đã thiết lập kết nối an toàn với máy chủ hợp pháp cho miền của người nhận.

Khám phá máy chủ thư của người nhận

Điều này thường đạt được nhất thông qua tra cứu DNS của bản ghi MX (Mail Exchange) trỏ đến một hoặc nhiều địa chỉ IP của máy chủ thư dự định nhận thư cho miền của người nhận. Tuy nhiên, có những cơ chế khác như bản ghi MTA-STS, SRV hoặc thậm chí là bản ghi A. Chúng tôi sẽ đề cập thêm một số yếu tố của MTA-STS bên dưới nhưng không đề cập đến các phương pháp tiếp cận bản ghi SRV/A (mặc dù chúng có chung điểm yếu).

Việc khám phá các máy chủ thư phụ thuộc vào DNS và phần lớn các truy vấn DNS vẫn dựa vào các gói UDP và do đó không có kết nối và không được mã hóa, khiến việc chặn và đưa vào các phản hồi giả mạo tương đối dễ dàng.

Mặc dù có các triển khai DNS sử dụng TCP, TLS và thậm chí cả DNS qua HTTPS , nhưng chúng khá phổ biến nhưng làm giảm khả năng chặn và tiêm giữa máy khách và máy chủ.

Tuy nhiên, việc triển khai TCP/TLS tập trung vào việc cải thiện hoặc bảo mật kết nối, bản thân chúng không cung cấp cơ chế để đảm bảo rằng dữ liệu, phản hồi đối với tra cứu DNS, là chính hãng và không bị can thiệp.

Đây là lúc DNSSEC phát huy tác dụng, nó cung cấp phương pháp ký kỹ thuật số được neo tin cậy để đảm bảo mọi phản hồi DNS cho các miền hỗ trợ DNSSEC đều có thể được xác thực bằng mật mã là chính hãng và có thẩm quyền.

DANE thì sao?

• DANE yêu cầu DNSSEC cho tất cả các tra cứu DNS, giúp giảm thiểu thành công rủi ro này.

• MTA-STS xuất bản các máy chủ thư, có thẩm quyền cho một miền, bằng cách liệt kê chúng trong tệp chính sách MTA-STS được lưu trữ trên máy chủ web. Mặc dù bản thân kết nối đến máy chủ web có thể là HTTPS (có xác thực chứng chỉ), nhưng việc tra cứu DNS của máy chủ web đó không yêu cầu phải an toàn.
• MTA-STS không bắt buộc sử dụng DNSSEC, trên thực tế, tôi hiểu rằng một trong những 'tính năng thiết kế' của nó là nó không phụ thuộc vào DNSSEC.

• Việc khám phá máy chủ thư miền của người nhận phụ thuộc vào DNS mà không có DNSSEC sẽ thiếu tính bảo mật để đảm bảo các phản hồi nhận được.
• DANE bắt buộc sử dụng DNSSEC, do đó, với tư cách là một phần mở rộng cho SMTP, đây là cơ chế hiệu quả nhất để bảo vệ chống lại rủi ro này.
• MTA-STS không bắt buộc sử dụng DNSSEC và mặc dù lưu trữ chính sách trên máy chủ được bảo mật HTTPS, vẫn dựa vào tra cứu DNS truyền thống.
• Tuy nhiên, MTA-STS có thể được triển khai với DNSSEC, điều này sẽ giảm thiểu phần lớn rủi ro này. Đây sẽ là đề xuất của tôi nếu bạn đang trong quá trình triển khai MTA-STS.

Thế giới chuyển sang HTTPS chỉ trong nháy mắt. Ngày nay, việc tìm thấy bất kỳ trang web nào không hỗ trợ HTTPS (ngay cả những trang không lấy chi tiết thẻ tín dụng của bạn) là điều rất bất thường. Tuy nhiên, email chưa thấy bước thay đổi tương tự về bảo mật và vẫn dựa vào cái mà chúng tôi gọi là “TLS cơ hội”. Trong TLS cơ hội, trước tiên, máy chủ sẽ tạo kết nối không an toàn, sau đó cố gắng đàm phán và nâng cấp kết nối lên TLS nhưng sẽ vui vẻ tiếp tục mà không có TLS nếu vì bất kỳ lý do gì, họ không thể đồng ý.

Vấn đề thực sự ở đây là “TLS cơ hội” ban đầu mở một kết nối không an toàn và nâng cấp nó lên TLS (được khởi tạo bởi phương pháp STARTTLS). Do đó, tương đối dễ dàng để chặn kết nối như vậy và ngăn chặn việc nâng cấp lên TLS bằng cách che dấu hỗ trợ STARTTLS từ máy chủ từ xa. Sau đó, các máy chủ thư TLS cơ hội sẽ tiếp tục trao đổi email mà không cần quan tâm hay cân nhắc. Tệ hơn nữa là cả người gửi và người nhận đều không biết rằng điều này đã xảy ra.

Cả hai bên trong kết nối TLS đều sử dụng chứng chỉ PKI, chứng chỉ này cũng có thể được sử dụng để cung cấp mức độ tin cậy bổ sung rằng các bên thực sự đúng như họ nói và có thể xác minh độc lập thông qua điểm neo tin cậy . Tuy nhiên, do việc lấy chứng chỉ từ các nhà cung cấp như LetsEncrypt dễ dàng như thế nào, điều này trở nên kém tin cậy hơn.

Trong thực tế, phần lớn các máy chủ email hỗ trợ một số dạng TLS và do đó, có khả năng khá cao là email của bạn đã được mã hóa khi đi qua Internet đến đích. Tuy nhiên, nó không giải quyết được nguy cơ tấn công MITM che giấu hỗ trợ TLS và cho phép các kết nối không được mã hóa.

Còn MTA-STS thì sao?

• MTA-STS giải quyết rủi ro này bằng cách (và giả sử bạn không ở chế độ 'thử nghiệm') yêu cầu ngầm rằng kết nối TLS phải được thiết lập để trao đổi email.

• DANE thực thi yêu cầu ngầm đối với kết nối TLS và do đó giảm thiểu rủi ro này.

• TLS cơ hội dựa vào kết nối không được mã hóa để thiết lập khả năng nâng cấp lên TLS và do đó dễ bị tấn công MITM.
• Cả DANE và MTA-STS đều yêu cầu hoàn toàn kết nối TLS trước khi trao đổi email, vì vậy chúng có hiệu quả trong việc đảm bảo ít nhất một kết nối TLS cơ bản được thiết lập.
• Chỉ riêng TLS là không đủ để gợi ý rằng một kết nối được bảo mật/mã hóa đầy đủ. Nhiều giao thức và bộ mật mã được triển khai trong TLS được coi là không an toàn (có thể cưỡng bức thô bạo). Bản thân đây là cả một chủ đề mà chúng tôi sẽ đề cập trong một bài viết sau.

Đây được cho là một bước trong quá trình thiết lập kết nối an toàn giữa các máy chủ thư. Tuy nhiên, theo quan điểm của tôi, nó là một yếu tố quan trọng đến mức nó xứng đáng là phần riêng của nó.

Nhận thấy sự phụ thuộc vào các giai đoạn trước, điều cần thiết là chúng tôi có thể xác thực thêm rằng máy chủ mà chúng tôi đang kết nối thực sự là máy chủ có thẩm quyền đối với miền của người nhận. Giai đoạn trước đã mô tả việc thiết lập kết nối TLS có thể bao gồm hoặc không bao gồm Xác minh chứng chỉ. Tuy nhiên, nói chung, tất cả Xác minh chứng chỉ thường làm là xác thực rằng tên máy chủ đã cho khớp với tên máy chủ được nêu chi tiết trong chứng chỉ trên máy chủ từ xa và tùy chọn nếu nó được gắn lại với mỏ neo tin cậy.

DANE tiến thêm một bước này bằng cách xuất bản bản ghi TLSA được bảo mật DNSSEC chứa dấu vân tay (và phương thức xác thực) cho chứng chỉ máy chủ thư đã cho. Điều này cung cấp một xác thực cuối cùng và đáng tin cậy để đảm bảo rõ ràng rằng máy chủ mà bạn kết nối đến đang xuất trình chứng chỉ cụ thể được quản trị viên DNS công nhận.

DANE thì sao?

• Xác thực chứng chỉ máy chủ dựa trên bản ghi TLSA được bảo mật DNSSEC vốn có của DANE và cung cấp con dấu phê duyệt cuối cùng để đảm bảo kết nối.

• MTA-STS không đi xa đến mức này, mục đích của nó là tập trung vào việc đảm bảo kết nối TLS là bắt buộc và không mở rộng để xác thực thẩm quyền của máy chủ thư.

Theo tôi, không có lý do hợp lý nào mà những điểm yếu này vẫn không được khắc phục ở phần lớn các nhà cung cấp dịch vụ thư tín. Công nghệ tồn tại để giải quyết chúng và ngày nay tương đối dễ triển khai. Giả định của tôi là việc người tiêu dùng thiếu nhận thức sẽ loại bỏ phần lớn động cơ khuyến khích các nhà cung cấp dịch vụ thư triển khai các công nghệ này.

MTA-STS cung cấp một số cải tiến quan trọng đối với các vấn đề của TLS cơ hội nhưng không đủ xa để giải quyết tất cả các điểm yếu. Thêm DNSSEC vào MTA-STS sẽ làm giảm một số rủi ro và sẽ là đề xuất của tôi (nếu DANE không phải là một tùy chọn dành cho bạn).

Tuy nhiên, DANE cung cấp một giải pháp toàn diện cho những điểm yếu được thảo luận trong bài viết này. Nếu bạn đang xem xét cả MTA-STS và DANE nhưng chỉ muốn chọn một, thì DANE sẽ là đề xuất của tôi.

Có khoảng 365 triệu tên miền được đăng ký trên toàn thế giới và chỉ có 3,7 triệu tên miền đã triển khai DANE (khoảng 1%).

Nếu chúng tôi xem xét các nhà cung cấp thư lớn nhất, chúng tôi lưu ý rằng Gmail đã triển khai MTA-STS nhưng chưa triển khai DANE hoặc thậm chí DNSSEC.

Tương tự, Microsoft đã triển khai MTA-STS cho Exchange Online trong năm nay và đã công bố ý định cung cấp DANE trong tương lai nhưng có thể phải mất vài năm nữa họ mới hỗ trợ cả bên ngoài và bên trong.