Giới thiệu
Lưu trữ ảo là thực hành phục vụ nhiều trang web trên cùng một máy chủ. Mặc dù nó là chuẩn mực hiện nay, nhưng điều này là không thể trong những ngày đầu của HTTP (các phiên bản trước 1.1).
Ban đầu, một máy chủ chỉ có thể lưu trữ nhiều trang web trên cùng một máy (tức là dưới cùng một địa chỉ IP) với điều kiện mỗi trang web được gán một cổng chuyên dụng. Đây không phải là một giải pháp lý tưởng vì các trình duyệt mặc định là cổng 80 cho HTTP, trừ khi người dùng chỉ định một cái khác. Do đó, hầu hết chủ sở hữu trang web đã chọn một máy chủ chuyên dụng để tránh nguy cơ người dùng không nhớ đúng số cổng và kết thúc trên một trang web khác.
Tuy nhiên, khi nhiều người dùng tham gia Web và nhiều thiết bị mạng bắt đầu xuất hiện trực tuyến, số lượng địa chỉ IP khả dụng bắt đầu giảm với tốc độ đáng báo động. Sự suy giảm dự đoán này, được gọi là Kiệt sức phạm vi địa chỉ IPv4, đã thúc đẩy ngành công nghiệp thiết kế và thực hiện các biện pháp đối phó khác nhau, như IPv6 (Người kế nhiệm của IPv4), có thể hỗ trợ nhiều địa chỉ hơn chúng ta sẽ cần. Thật không may, mặc dù IPv6 là một giải pháp khả thi, việc áp dụng nó đã khá chậm. Dựa theo Thống kê IPv6 của Google, tại thời điểm viết bài này, chỉ có khoảng 25% thiết bị Internet được triển khai qua IPv6.
Lưu trữ ảo cũng được triển khai như một biện pháp giảm thiểu sớm cho vấn đề cạn kiệt, với sự ra đời của Host tiêu đề trong HTTP 1.1. Các trình duyệt giao tiếp qua HTTP 1.1 hiện có thể kết nối với cổng của máy chủ 80 và bao gồm tên miền (ví dụ www.ssl.com) của trang web họ muốn truy cập trong Host tiêu đề. Bất kể có bao nhiêu trang web mà một máy chủ được lưu trữ trên cùng một cổng, nó có thể sử dụng thông tin này để xác định trang web chính xác và trả về nội dung của nó.
HTTPS và lưu trữ ảo
Tuy nhiên, nhiều báo cáo được công bố về các lỗ hổng mạng và các cuộc tấn công chống lại người dùng web đã thúc đẩy ngành công nghiệp này bắt đầu chuyển từ HTTP không an toàn sang HTTPS thay thế an toàn hơn. Việc áp dụng rộng rãi HTTPS đã cải thiện bảo mật người dùng tổng thể. Tuy nhiên, các cải tiến bổ sung của nó cũng đã làm tăng độ phức tạp chung của giao tiếp web.
Về nguyên tắc, HTTPS khá giống với HTTP, ngoại trừ giao tiếp HTTPS giữa trình duyệt và máy chủ được mã hóa. Tóm lại, HTTPS yêu cầu máy chủ cung cấp cho trình duyệt chứng chỉ SSL hợp lệ được cấp bởi một tổ chức đáng tin cậy công khai cơ quan cấp chứng chỉ (CA), chẳng hạn như SSL.com. Sau đó, một trình duyệt có thể sử dụng khóa chung có trong chứng chỉ để thiết lập kênh liên lạc được mã hóa với máy chủ. Hơn nữa, chứng chỉ được cấp cho một tên miền cụ thể, mà trình duyệt sẽ kiểm tra xem có khớp với miền mà người dùng muốn truy cập hay không. Do đó, bất kể máy chủ lưu trữ bao nhiêu trang web, các trình duyệt đều mong đợi tìm thấy chứng chỉ SSL hợp lệ cho trang web mà họ đã yêu cầu.
Người đọc chú ý có thể đã cảm nhận được vấn đề: trình duyệt yêu cầu chứng chỉ của trang web chính xác để thiết lập kênh được mã hóa và gửi Host tiêu đề, trong khi máy chủ cần Host tiêu đề để xác định đúng chứng chỉ của trang web. Đây là một bài toán gà và trứng cổ điển.
Rõ ràng là lưu trữ ảo như được hình thành cho HTTP không hoạt động cho HTTPS, bởi vì các điều khiển bảo mật ngăn các trình duyệt gửi Host thông tin đến máy chủ. Tuy nhiên, với vấn đề cạn kiệt IPv4 vẫn chưa được giải quyết và việc áp dụng công nghệ đám mây ngày càng tăng của ngành (yêu cầu cân bằng tải và nhiều máy chủ phụ trợ không hoạt động), lưu trữ ảo vẫn là một điều cần thiết.
Chứng chỉ đa miền thì sao?
Một giải pháp được đề xuất cho vấn đề này là sử dụng đa miền hoặc Chứng chỉ SAN. Một chứng chỉ SAN duy nhất có thể bảo mật hàng trăm tên miền khác nhau và các trình duyệt sẽ không phàn nàn nếu họ tìm thấy tên miền mà họ đang cố truy cập bên trong danh sách miền của chứng chỉ SAN. Sau khi kênh mã hóa được định cấu hình, trình duyệt có thể gửi Host đến máy chủ và tiếp tục như trong bất kỳ trường hợp nào khác. Đây là một ý tưởng tuyệt vời sử dụng công nghệ đã có sẵn và sẵn có, nhưng các cơ chế tương tự để đảm bảo tính bảo mật của chứng chỉ SAN cũng đã tạo ra một số tác dụng phụ tiềm ẩn không mong muốn:
Chứng chỉ SAN là một công cụ tốt để bảo mật nhiều tên miền thuộc sở hữu của cùng một thực thể (người, công ty hoặc tổ chức), nhưng chúng hơi không thực tế để sử dụng trong lưu trữ chia sẻ; Bất cứ khi nào một tên miền mới sẵn sàng được thêm vào hoặc xóa khỏi chứng chỉ, một chứng chỉ mới với danh sách tên miền mới nhất phải được CA cấp và triển khai lại trên tất cả các tên miền.
Hơn nữa, chứng chỉ SAN chỉ có thể được cấp dưới dạng Tổ chức được xác thực (OV) hoặc Xác thực mở rộng (EV) if tất cả các tên miền thuộc cùng một tổ chức. Các mức xác nhận này đề cập đến số lượng và các loại thông tin của chủ sở hữu chứng chỉ tiềm năng được CA xác minh trước khi cấp cho họ giấy chứng nhận. Nó đã được chứng minh rằng mức độ xác nhận càng cao, người dùng càng tin tưởng vào trang web và niềm tin của người dùng có thể ảnh hưởng đến tỷ lệ chuyển đổi và nhận diện thương hiệu.
Cuối cùng, khá phổ biến trong môi trường lưu trữ web được chia sẻ cho một công ty để chia sẻ máy chủ với các doanh nghiệp hoặc tổ chức khác (ngay cả với các đối thủ cạnh tranh). Vì các tên miền trong chứng chỉ SAN được liệt kê công khai, chủ sở hữu doanh nghiệp có thể miễn cưỡng chia sẻ cùng một chứng chỉ với các công ty bên thứ ba.
Mặc dù chứng chỉ SAN là công cụ mạnh mẽ và linh hoạt với vô số ứng dụng, nhưng những vấn đề này đã thúc đẩy IETF - cơ quan quản lý các tiêu chuẩn Internet - tìm kiếm các phương pháp tiếp cận phù hợp hơn cho vấn đề cụ thể của các trang web HTTPS được lưu trữ ảo.
Tên máy chủ để giải cứu
Các giải pháp đã được thực hiện dưới hình thức Tên máy chủ (SNI) mở rộng của TLS giao thức (một phần của HTTPS liên quan đến mã hóa).
SNI cho phép các trình duyệt chỉ định tên miền mà họ muốn kết nối trong TLS bắt tay (thương lượng chứng chỉ ban đầu với máy chủ). Do đó, các trang web có thể sử dụng chứng chỉ SSL của riêng chúng trong khi vẫn được lưu trữ trên địa chỉ IP và cổng được chia sẻ, vì máy chủ HTTPS có thể sử dụng thông tin SNI để xác định chuỗi chứng chỉ thích hợp cần thiết để thiết lập kết nối.
Sau đó, khi kênh truyền thông được mã hóa đã được định cấu hình, trình duyệt có thể tiến hành đưa tên miền của trang web vào Host và tiếp tục như bình thường. Về cơ bản, SNI thực hiện chức năng tương tự như HTTP Host tiêu đề trong quá trình tạo kết nối được mã hóa.
Thủ thuật đơn giản này cuối cùng đã cho phép các máy chủ lưu trữ nhiều trang web HTTPS trên cùng một cổng. Tuy nhiên, như với hầu hết các công nghệ Internet, SNI có một số hạn chế.
Mối quan tâm hỗ trợ của SNI
Mặc dù SNI đã khá hoàn thiện kể từ khi nó được soạn thảo lần đầu tiên vào năm 1999, nhưng vẫn còn một số trình duyệt cũ (IE trên Windows XP) và hệ điều hành (phiên bản Android <= 2.3) không hỗ trợ nó. Để có danh sách đầy đủ các trình duyệt và hệ điều hành hỗ trợ SNI, vui lòng xem qua cái bàn này.
Mặc dù thị phần của các trình duyệt không hỗ trợ SNI (và phần mở rộng là sự xuất hiện của điều này xảy ra) là rất nhỏ so với các trình duyệt hiện đại, nếu một trình duyệt không nhận ra SNI, nó sẽ trở lại chứng chỉ SSL mặc định và có khả năng tạo ra lỗi không khớp tên phổ biến.
Nhiều công ty, chẳng hạn như Google, triển khai SNI cho các khách hàng hỗ trợ nó và quay lại chứng chỉ SAN cho các trường hợp hiếm gặp. Đương nhiên, vấn đề này dự kiến sẽ giảm bớt khi ngày càng nhiều người dùng và chủ doanh nghiệp nâng cấp hệ thống của họ lên các công nghệ hiện đại.
Mối quan tâm riêng tư của SNI
Phiên bản ổn định hiện tại của TLS (phiên bản 1.2) truyền phần ban đầu của quá trình bắt tay và theo thông tin SNI mở rộng, không được mã hóa. Do đó, kẻ tấn công mạng có thể khám phá lịch sử web của người dùng, mặc dù bản thân các thông tin liên lạc trên web đã được mã hóa hoàn toàn.
Các nhà cung cấp dịch vụ đám mây khác nhau, như Amazon hoặc Google, đã cho phép một cách giải quyết (bẩn) được gọi là mặt trận tên miền. Giao diện tên miền có thể ngăn việc tiết lộ lịch sử web vì nó làm xáo trộn thông tin SNI bằng cách sử dụng tên máy chủ của nhà cung cấp đám mây trong TLS thương lượng và trang web đích trong tiêu đề HTTP. Tuy nhiên, phương pháp này không còn khả thi nữa, vì Google và Amazon đã tuyên bố công khai rằng họ hỗ trợ vô hiệu hóa cho mặt trước tên miền trong các dịch vụ của họ kể từ tháng 2018 năm XNUMX.
May mắn thay, một giải pháp hệ thống hơn đã được đề xuất như một dự thảo thử nghiệm chi tiết SNI được mã hóa (ESNI) tiện ích mở rộng mới nhất TLS phiên bản 1.3. ESNI mã hóa thông tin SNI, do đó giảm thiểu mọi lo ngại về quyền riêng tư. Không may, TLS 1.3 vẫn chưa được ngành công nghiệp áp dụng rộng rãi, mặc dù TLS 1.3 đang dần trở thành giao thức bảo mật mạng thực tế. Hãy theo dõi các bài viết trong tương lai từ chúng tôi về tình trạng ESNI và quyền riêng tư của HTTPS và TLS.
Kết luận
Tóm lại, với SNI, bạn có thể lưu trữ hàng triệu trang web HTTPS trên một máy chủ. Tuy nhiên, tùy thuộc vào trường hợp cá nhân của bạn, chứng chỉ SAN có thể phù hợp với bạn hơn. Những lo ngại về quyền riêng tư về SNI vẫn tồn tại, mặc dù cũng tồn tại một giải pháp tiềm năng với ESNI. Trong mọi trường hợp, sử dụng một hoặc kết hợp cả hai phương pháp này, bạn có thể dễ dàng triển khai lưu trữ ảo cho tất cả các trang web của mình với nỗ lực tối thiểu.
Nếu bạn có thêm câu hỏi về SNI hoặc không biết làm thế nào để lựa chọn giữa SAN và SNI, chúng tôi luôn sẵn lòng trả lời tất cả các câu hỏi của khách hàng về PKI nhu cầu. Chỉ cần gửi email cho chúng tôi tại support@ssl.com và một chuyên gia sẽ giúp bạn.
