“Google.com” không được bảo vệ HSTS?

Question

Vấn đề:

Thông thường mọi người nhập google.comtrực tiếp vào thanh địa chỉ của trình duyệt mà không bao gồm tiền tố http://hoặc https://.

Sử dụng Chrome DevTools trong một phiên ẩn danh mới, tôi đã chạy thử nghiệm sau:

CÁC BƯỚC:
-----------------
Nhập "google.com" (hoặc tương đương "http://google.com") trực tiếp trong 
thanh địa chỉ của trình duyệt.

 1. Yêu cầu: http://google.com;
    Phản hồi: Mã trạng thái: 301 Đã chuyển vĩnh viễn
              Vị trí: http://www.google.com.vn/
              Cache-Control: public, max-age = 2592000

 2. Yêu cầu: http://www.google.com;
    Phản hồi: Mã trạng thái: Đã tìm thấy 302
              Vị trí: https://www.google.com/?gws_rd=ssl

 3. Yêu cầu: https://www.google.com/?gws_rd=ssl;
    Phản hồi: Mã trạng thái: 200
              vận chuyển-an ninh nghiêm ngặt: max-age = 31536000

LƯU Ý: 
-----------------
* Để nhận được kết quả tương tự, hãy bắt đầu một phiên ẩn danh mới (đóng tất cả chế độ ẩn danh 
  cửa sổ và mở một cửa sổ mới). Nếu bạn đã mở cửa sổ ẩn danh
  có thể không nhận được kết quả tương tự. Đã chọn "tắt bộ nhớ cache" cũng không giúp được gì.

* Nếu bạn lặp lại thử nghiệm từ cùng một phiên ẩn danh, bạn sẽ nhận thấy 
  sau những khác biệt so với lần đầu tiên:

    * Yêu cầu 1: Nếu "tắt bộ nhớ cache" không được chọn (bắt chước trình duyệt của 
                 hành vi trong quá trình sử dụng bình thường), phản hồi sẽ từ bộ nhớ cache 
                 do phản hồi "Cache-Control: public, max-age = 2592000" 
                 tiêu đề trở lại lần đầu tiên. Điều này có nghĩa là http
                 yêu cầu không được gửi đi (mặc dù nó vẫn hiển thị 301 
                 phản hồi) đó có lẽ là một điều tốt.

    * Yêu cầu 2: Phản hồi sẽ là 307 thay vì 302. Điều này là do 
                 "nghiêm ngặt-vận chuyển-bảo mật: max-age = 31536000" được trả về bởi 
                 yêu cầu thứ ba lần đầu tiên. Đây là trường hợp bất kể
                 về việc "tắt bộ nhớ cache" có được chọn hay không.

* Sau khi trình duyệt biết rằng miền được bảo vệ bằng HSTS (thông qua 
  Tải trước HSTS hoặc tiêu đề phản hồi STS) trình duyệt sẽ chuyển hướng "nội bộ"
  tất cả các yêu cầu http tới https cho miền đó. Các chuyển hướng này được hiển thị trong
  tab mạng là "Mã trạng thái: Chuyển hướng nội bộ 307" (đây là loại 
  gây hiểu lầm vì có vẻ như phản hồi đến từ máy chủ khi ở 
  thực tế tất cả đều diễn ra trong trình duyệt. Chú ý rằng không có
  "Địa chỉ từ xa" trong phần "Chung" cho những yêu cầu này

* Một cách khác (có lẽ dễ dàng hơn) để kiểm tra xem miền có được bảo vệ bằng HSTS hay không là 
  vào miền trong https://hstspreload.org/ nhưng có những cảnh báo! 
  https://hstspreload.org/ báo cáo những điều sau cho "www.google.com":
     - "Lỗi phản hồi: Không có tiêu đề HSTS trên phản hồi."
     - "` http: // www.google.com` không chuyển hướng đến `https: // www.google.com`"
  Cả hai phát hiện này đều không phù hợp với những gì quan sát được trong mạng 
  trong thử nghiệm trên! Tôi đã gửi email danh sách gửi thư hstspreload và
  đã nhận được phản hồi thú vị sau: "Máy chủ cho 
  http://www.google.com không phải lúc nào cũng chuyển hướng http đến https, đó là lý do tại sao điều này 
  lỗi xuất hiện. Ví dụ: nếu tôi sử dụng curl, tôi không nhận được chuyển hướng. "
-----------------

Mối quan tâm về quyền riêng tư / bảo mật:

• Yêu cầu ban đầu google.comđược thực hiện httpvì google.comkhông có trong danh sách tải trước HSTS. Yêu cầu này dễ bị tấn công MITM.

• Trình duyệt https://google.comkhông bao giờ được chuyển hướng đến , do đó tiêu đề STS không bao giờ được đặt cho miền này. Điều này có nghĩa là ngay cả các yêu cầu trong tương lai google.comsẽ không được bảo vệ HSTS và do đó có thể dễ bị tấn công MITM!

  Cần lưu ý rằng tiêu đề phản hồi max-age = 2592000 (30 ngày) của cache-control được bao gồm trong chuyển hướng 301 ban đầu dường như cung cấp một mức bảo vệ tương tự như những gì HSTS cung cấp vì nó khiến các yêu cầu trong tương lai http://google.comđược xử lý "nội bộ" bởi bộ nhớ cache (và quan trọng là được chuyển hướng đến miền "www.google.com" được bảo vệ bằng HSTS). Mặt khác, kiểm soát bộ nhớ cache max-age được đặt thành hết hạn sau 30 ngày (ngắn hơn nhiều so với những gì HSTS max-agethường được đặt thành) và, quan trọng nhất, không giống như HSTS max-age được làm mới trên mọi httpsyêu cầu được thực hiện đối với miền hỗ trợ HSTS, kiểm soát bộ nhớ cache max agekhông được làm mới cho đến khi một httpyêu cầu không an toàn mới được thực hiện! Điều này có nghĩa là các yêu cầu của bạn google.comcó thể bị chặn thường xuyên 30 ngày một lần.

• Yêu cầu www.google.comđược thực hiện qua http và dễ bị tấn công MITM. Ít nhất trong trường hợp này, phản hồi là chuyển hướng 302 https://www.google.commà bao gồm tiêu đề STS. Điều này có nghĩa là mọi yêu cầu tiếp theo http://www.google.comsẽ được trình duyệt chuyển hướng "nội bộ" đến https, như đã lưu ý ở trên, HSTS max-ageđược làm mới theo mọi yêu cầu. Vì vậy, miễn là trình duyệt của bạn đưa ra yêu cầu https://www.google.comít nhất mỗi năm một lần (đó là max-agethời hạn STS được đặt thành), tất cả các yêu cầu đối với miền đó sẽ được bảo vệ HSTS.

TL; DR - "google.com" không được bảo vệ bằng HSTS và có vẻ như các yêu cầu có khả năng bị tấn công MITM thường xuyên 30 ngày một lần (hoặc thường xuyên hơn nếu bộ nhớ cache bị xóa hoặc sử dụng chế độ ẩn danh).

Điều này có thể không quá tệ vì những lý do sau:

• Tất cả các cookie quan trọng .google.comvà www.google.comchắc chắn nhất đều có securecờ được đặt.
• google.comdường như không làm gì khác hơn là chuyển hướng đến www.google.combất kỳ yêu cầu google.comnào trên thực tế sẽ chỉ đến đường dẫn gốc (Do đó, bản thân URL sẽ không thú vị đối với kẻ nghe trộm).
• Các miền phụ của Google gửi / nhận dữ liệu nhạy cảm hơn (ví dụ: gmail.com, account.google.com ...) nằm trong danh sách tải trước HSTS. Vì vậy, ngay cả khi kẻ tấn công thiết lập một cái gì đó như sslsplit và người dùng kết thúc với kẻ tấn công bị kiểm soát http://www.google.com(điều này đã đủ khó để lấy vì nó yêu cầu người dùng không nhận thấy biểu tượng ổ khóa bị thiếu), các miền được tải trước HSTS sẽ vẫn được bảo vệ . Do đó, kẻ tấn công sẽ cần ngăn người dùng điều hướng đến bất kỳ tên miền phụ nào trong số đó.

Câu hỏi

1. Điều gì có thể là lý do tại sao Google không bật HSTS cho google.com
2. Điều gì có thể là lý do tại sao Google chỉ bật tiêu đề STS www.google.commà chưa thêm miền đó vào danh sách tải trước HSTS?

Answer 1

Tình hình hiện tại

Đúng là, kể từ tháng 10 năm 2020, Google không bật HSTS google.commà chỉ bật www.google.comvà thực hiện chuyển hướng trước tiên đến wwwrồi đến https://. Ngay cả khi đã bật tiêu đề HSTS google.com, trình duyệt sẽ không nhìn thấy nó và có thể lưu vào bộ nhớ cache. Chỉ www.google.comđược bảo vệ bởi HSTS.

Thực hành tốt nhất

Nó cũng được khuyến nghị như là các phương pháp hay nhất của Hội đồng CIO Liên bang , rằng:

Ở dạng mạnh nhất và được đề xuất, chính sách HSTS bao gồm tất cả các tên miền phụ và cho thấy sự sẵn sàng được "tải trước" vào các trình duyệt:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 

Khi sử dụng biểu mẫu này, hãy ghi nhớ:

• Chính sách nên được triển khai tại https://domain.gov, không https://www.domain.gov.
• Tất cả các miền phụ được liên kết với miền mẹ phải hỗ trợ HTTPS. (Họ không nhất thiết phải có chính sách HSTS của riêng mình.)

Bảng Cheat Bảo mật Vận chuyển Nghiêm ngặt OWASP HTTP cho biết thêm (cũng được lưu ý trong RFC 6797, 14.4 ):

Cookie có thể bị thao túng từ các miền phụ, do đó, việc bỏ qua includeSubDomainstùy chọn sẽ cho phép một loạt các cuộc tấn công liên quan đến cookie mà HSTS sẽ ngăn chặn bằng cách yêu cầu chứng chỉ hợp lệ cho miền phụ. Việc đảm bảo cờ an toàn được đặt trên tất cả các cookie cũng sẽ ngăn chặn, một số, nhưng không phải tất cả, các cuộc tấn công giống nhau.

Điều này chỉ có thể đạt được bằng cách chuyển hướng đầu tiên đến HTTPS.

Tại sao?

Tuy nhiên, chúng tôi chỉ có thể cho biết điều gì sẽ tốt hơn, nhưng chúng tôi không thể trả lời tại sao một số không tuân theo các nguyên tắc này. Chỉ có Google mới biết tại sao họ lại triển khai theo cách này. Nó không phải là thiếu kiến ​​thức và khả năng, vì họ đã làm điều đó gmail.com, ví dụ , hiện đang nằm trong danh sách tải trước HSTS.

Bạn có thể tìm được câu trả lời gần nhất của mình bằng cách đọc bài Đưa HSTS đến www.google.com của Jay Brown từ Blog Bảo mật của Google. Từ bài viết này từ tháng 7 năm 2016, chúng tôi có thể phát hiện ra rằng đó là cố ý do tính phức tạp của trang web khổng lồ và để tương thích ngược với các dịch vụ cũ .

Thông thường, thực hiện HSTS là một quá trình tương đối cơ bản. Tuy nhiên, do sự phức tạp đặc biệt của Google, chúng tôi cần thực hiện thêm một số công việc chuẩn bị mà hầu hết các miền khác không cần phải làm. Ví dụ: chúng tôi phải giải quyết nội dung hỗn hợp, HREF không hợp lệ, chuyển hướng đến HTTP và các vấn đề khác như cập nhật các dịch vụ cũ có thể gây ra sự cố cho người dùng khi họ cố gắng truy cập vào miền chính của chúng tôi.

Quá trình này không phải là không có cạm bẫy của nó. Có lẽ đáng nhớ nhất là chúng tôi đã vô tình làm hỏng Trình theo dõi ông già Noel của Google ngay trước Giáng sinh năm ngoái (đừng lo lắng - chúng tôi đã sửa lỗi này trước khi ông già Noel và tuần lộc của ông ấy thực hiện chuyến đi của họ).