Tin tức mới xuất hiện rằng Apple, Cloudflare, Fastly và Mozilla đã hợp tác để tăng cường mã hóa cơ chế Nhận dạng tên máy chủ của HTTPS tại IETF 102 Hackathon như được chỉ ra bởi một tweet từ Nick Sullivan của Cloudflare. Dòng tweet chúc mừng nhóm kết hợp từ bốn gã khổng lồ công nghệ bằng cách nói 'Công việc tuyệt vời' và chia sẻ ở đó theo liên kết đến các máy chủ đang hoạt động tại esni.examp1e.net và cloudflare-esni.com .
Tác phẩm tuyệt vời tại cuộc thi hackathon IETF 102 của nhóm SNI được mã hóa bao gồm những người từ @Cloudflare @ nhanh @mozilla và @táo . Hiện đã có triển khai trong BoringSSL, NSS và picotls.
Máy chủ đang hoạt động trực tiếp tại https://t.co/sLI9xLRjlK và https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) Ngày 15 tháng 7 năm 2018
IETF Hackathon là một nền tảng mời các nhà phát triển trẻ và những người đam mê công nghệ cùng tham gia soạn thảo các giải pháp cho các vấn đề liên quan đến công nghệ mà người dùng thông thường phải đối mặt ngày nay. Các sự kiện được tham gia miễn phí, mở cho tất cả mọi người và chúng khuyến khích tinh thần đồng đội thay vì cạnh tranh. IETF Hackathon năm nay được tổ chức tại Montreal vào ngày 14thứ tựvà 15thứ tựcủa tháng Bảy. Có vẻ như thành tựu nổi bật nhất của nó là mã hóa Chỉ báo tên máy chủ (SNI) của Bảo mật tầng truyền tải (TLS), một vấn đề đã gây khó khăn cho các nhà phát triển trong thập kỷ qua, một vấn đề mà các thành viên của Apple, Cloudflare, Fastly. và Mozilla hiện đã đề xuất một giải pháp cho.
Sự kiện IETF Hackathon. IETF
Đã có một sự thay đổi toàn cầu rõ ràng từ Giao thức truyền siêu văn bản (HTTP) sang Chỉ báo tên máy chủ bảo mật lớp truyền tải Giao thức truyền siêu văn bản an toàn (TLS SNI HTTPS) trong thập kỷ rưỡi qua. Các vấn đề Điểm xuất phát từ việc tối ưu hóa hệ thống TLS SNI HTTPS là khả năng tin tặc sử dụng SNI trái với mục đích của nó để phù hợp với quá trình truyền dữ liệu để giải mã sau này.
Trước sự phát triển của SNI, rất khó để thiết lập kết nối an toàn tới nhiều máy chủ ảo bằng cách sử dụng cùng một lần bắt tay máy khách đầu tiên. Khi một địa chỉ IP tương tác với một máy chủ, cả hai trao đổi “hellos”, máy chủ gửi chứng chỉ của nó, máy tính gửi khóa khách của nó, cả hai trao đổi lệnh “ChangeCipherSpec” và sau đó tương tác kết thúc khi kết nối được thiết lập. Điều này nghe có vẻ dễ dàng theo cách người ta vừa nói nhưng quá trình này bao gồm nhiều trao đổi và phản hồi, điều này dễ gây ra khá nhiều vấn đề khi số lượng máy chủ được giao tiếp tăng lên. Nếu tất cả các trang web đều sử dụng cùng một chứng chỉ thì điều này không có nhiều vấn đề, nhưng tiếc là hiếm khi xảy ra trường hợp đó. Khi nhiều trang web gửi đi gửi lại nhiều chứng chỉ khác nhau, máy chủ sẽ khó xác định chứng chỉ nào mà máy tính đang tìm kiếm và trong mạng lưới trao đổi phức tạp, rất khó để xác định ai đã gửi cái gì và khi nào, do đó chấm dứt toàn bộ hoạt động với một thông báo cảnh báo hoàn toàn.
TLS SNI sau đó được giới thiệu vào tháng 6 năm 2003 thông qua hội nghị thượng đỉnh IETF và mục đích mà nó phục vụ, theo một nghĩa nào đó, là tạo thẻ tên cho các máy tính và dịch vụ liên quan đến web trao đổi. Điều này làm cho quá trình trao đổi hello giữa máy chủ và máy khách trở nên dễ dàng hơn nhiều vì máy chủ được tạo ra để có thể cung cấp các chứng chỉ chính xác cần thiết và cả hai đã có thể trao đổi cuộc trò chuyện của riêng mình mà không phải bối rối về việc ai đã nói gì. Nó giống như việc có tên liên hệ cho các cuộc trò chuyện và không bị nhầm lẫn về nguồn tin nhắn đến từ đâu và cũng có thể trả lời từng truy vấn một cách thích hợp, cung cấp tài liệu phù hợp cho bất kỳ máy tính nào cần. Định nghĩa SNI này chính xác là thứ đã dẫn đến vấn đề lớn nhất với phương pháp tối ưu hóa quy trình trao đổi này.
Cuộc đấu tranh mà nhiều công ty gặp phải khi chuyển sang HTTPS là sự thích ứng của nhiều chứng chỉ sang định dạng SNI với các địa chỉ IP riêng lẻ để thực hiện các yêu cầu cho từng chứng chỉ. Những gì TLS đã làm cho họ là làm cho việc tạo chứng chỉ để phản hồi các yêu cầu như vậy trở nên đơn giản hơn và những gì SNI đã làm được là loại bỏ nhu cầu về địa chỉ IP chứng chỉ chuyên dụng được cá nhân hóa bằng cách đưa vào toàn bộ hệ thống nhận dạng trên toàn bộ mạng internet. Điều đi kèm với sự nâng cấp của thế kỷ này là nó cho phép tin tặc sử dụng “tên liên lạc” đã được thiết lập để theo dõi, chuyển dữ liệu và trích xuất thông tin họ cần để giải mã ở giai đoạn sau.
Mặc dù TLS cho phép dữ liệu được gửi qua lại trong một kênh được mã hóa, với SNI đảm bảo rằng nó đến đích chính xác, TLS cũng cung cấp phương tiện để tin tặc giám sát hoạt động trực tuyến và khớp nó với nguồn của nó bằng cách theo dõi các yêu cầu DNS, địa chỉ IP và các luồng dữ liệu. Mặc dù các chính sách mã hóa SNI chặt chẽ hơn đã được thực hiện bằng cách chuyển thông tin DNS qua kênh TLS, nhưng vẫn còn một cửa sổ nhỏ để tin tặc có thể sử dụng điều này làm phương tiện nhận dạng để theo dõi phần thông tin mà chúng muốn trích xuất và cô lập nó. sự giải mã. Các máy chủ phức tạp đối phó với lưu lượng lớn hơn của dữ liệu được mã hóa TLS sử dụng SNI văn bản thuần túy để gửi thông tin liên lạc trong máy chủ của họ và đây là điều giúp tin tặc dễ dàng xác định các kênh và luồng thông tin mà chúng muốn theo dõi. Sau khi tin tặc có thể trích xuất thông tin SNI của dữ liệu quan tâm, anh ta / anh ta có thể thiết lập phát lại lệnh giả trong kết nối TLS riêng biệt với máy chủ, gửi thông tin SNI bị đánh cắp và truy xuất thông tin được liên kết với nó. Đã có một số nỗ lực để giải quyết vấn đề SNI này trước đây nhưng hầu hết đều đi ngược lại nguyên tắc đơn giản mà SNI hoạt động để biến nó thành một phương pháp nhận dạng thuận tiện cho các máy chủ.
Quay lại hội nghị lần đầu tiên làm việc để thiết lập phương pháp này, những người tham gia từ bốn gã khổng lồ công nghệ đã quay trở lại hội nghị ở Montreal để phát triển mã hóa cho TLS SNI bởi vì mặc dù hiệu quả cao hơn trong hệ thống liền kề đa HTTPS, bảo mật vẫn là một mối quan tâm. nhiều như nó đã làm trước đây.
Để che giấu SNI trong TLS, “Dịch vụ ẩn” phải được giữ dưới màn hình của “Dịch vụ biên giới” mà tin tặc có thể nhìn thấy. Nếu không có khả năng quan sát trực tiếp dịch vụ ẩn, tin tặc sẽ bị đánh lừa bởi lớp ngụy trang phía trước mà nó ẩn dưới dạng văn bản thuần túy mà không thể xác định các thông số dịch vụ bí mật cơ bản được sử dụng để chuyển tiếp dữ liệu được mã hóa. Khi người quan sát lần theo dấu vết của dịch vụ phía trước, dữ liệu sẽ bị xóa khỏi kênh được quan sát khi nó được chuyển hướng đến dịch vụ ẩn dự kiến của nó, lúc này tin tặc sẽ mất dấu. Vì máy chủ cũng sẽ được tiếp xúc với dịch vụ phía trước, khi dữ liệu đi đến đó, một tín hiệu SNI song song thứ hai sẽ được gửi đến dịch vụ phía trước để chuyển hướng dữ liệu đến dịch vụ ẩn và trong quá trình thay đổi hướng này, hacker sẽ bị mất trong web của máy chủ. Cơ chế vé đôi này được phát triển thêm thành vé kết hợp dưới cùng một SNI. Khi một phần dữ liệu được gửi vào máy chủ, dữ liệu tạo ra một giám đốc lại SNI hợp tác và cả hai làm việc cùng nhau để đưa dữ liệu được mã hóa TLS đến nơi nó cần đến. Nếu không có khả năng bẻ khóa dịch vụ giao diện người dùng ngẫu nhiên bao gồm cả hai đường dẫn SNI, tin tặc sẽ không thể lần theo dấu vết của dữ liệu nhưng máy chủ vẫn có thể kết nối cả hai và giải mã dịch vụ ẩn làm vị trí cuối cùng của dữ liệu. Điều này cho phép các máy chủ tiếp tục sử dụng SNI để tối ưu hóa việc truyền dữ liệu của chúng trong mã hóa TLS đồng thời đảm bảo rằng tin tặc không thể lợi dụng cơ chế SNI.
