Apache: Xác thực chuỗi tin cậy SSL để ngăn chặn các cuộc tấn công MITM?

11

Tôi mới nhận ra rằng các cuộc tấn công trung gian SSL phổ biến hơn nhiều so với tôi nghĩ, đặc biệt là trong môi trường công ty. Tôi đã nghe nói và thấy mình có một số doanh nghiệp có máy chủ proxy SSL minh bạch. Tất cả khách hàng được cấu hình để tin tưởng chứng chỉ proxy này. Về cơ bản, điều này có nghĩa là về mặt lý thuyết, chủ nhân có thể chặn lưu lượng được mã hóa SSL mà không có bất kỳ cảnh báo nào trong trình duyệt bật lên. Như đã đề cập ở trên, khách hàng đi kèm với chứng chỉ được tin cậy. Điều này chỉ có thể được tiết lộ bằng cách xác nhận thủ công chứng chỉ đang được sử dụng.

Đối với tôi, dường như nhà tuyển dụng sử dụng vị trí ưu việt của mình để theo dõi lưu lượng SSL của nhân viên. Đối với tôi, điều này làm cho toàn bộ khái niệm về SSL không đáng tin cậy. Tôi đã tự mình thử nghiệm thành công một thiết lập tương tự bằng cách sử dụng mitmproxy và có thể đọc được giao tiếp giữa máy khách và máy chủ ngân hàng điện tử của tôi. Đây là thông tin không nên tiết lộ cho bất cứ ai.

Vì vậy, câu hỏi của tôi khá đơn giản: Làm thế nào tôi có thể xác nhận chuỗi tin cậy ở phía máy chủ? Tôi muốn đảm bảo khách hàng sử dụng chứng chỉ máy chủ của tôi và chỉ một chuỗi tin cậy. Tôi tự hỏi nếu điều này có thể đạt được bằng cấu hình SSL của Apache? Điều này sẽ thuận tiện vì nó có thể được áp dụng cho nhiều ứng dụng một cách dễ dàng. Nếu điều này là không thể, có ai biết một cách để làm điều này trong PHP không? Hay bạn có bất kỳ đề nghị khác?

— Aileron79
nguồn

1

Sẽ ổn nếu nhà tuyển dụng thấy nhân viên giao thông. Bạn đang sử dụng tài nguyên của nhà tuyển dụng (pc, kết nối mạng, v.v.), đây không phải là tài nguyên của bạn. Và nếu bạn lo lắng rằng trình giả lập có thể thấy dữ liệu bạn truyền đến tài khoản ngân hàng của bạn - hãy thực hiện tại nhà, không phải tại nơi làm việc. Và những nỗ lực vi phạm chính sách bảo mật của công ty có thể là một chủ đề cho tòa án chống lại bạn.

— Tiền điện tử

2

Ở nhiều công ty châu Âu việc sử dụng thiết bị văn phòng tư nhân được quy định trong hợp đồng lao động. Trong công ty nơi tôi làm việc tôi có thể lướt web riêng tư, đó không phải là vấn đề. Có những trường hợp ngoại lệ như khiêu dâm, chia sẻ tập tin, vv Đồng thời có những luật không cho phép các công ty gián điệp nhân viên của họ. Do đó, đối với tôi - và nhiều người khác - KHÔNG ổn khi nhà tuyển dụng chặn lưu lượng nhân viên vì điều này rõ ràng bị cấm trong khi lướt web riêng tư được chấp nhận ở nhiều công ty.

— Aileron79

2

Hầu hết (theo kinh nghiệm của tôi) các máy trạm thuộc sở hữu của Chính phủ Hoa Kỳ bao gồm hai thông báo này mỗi lần đăng nhập: "Truyền thông sử dụng hoặc dữ liệu được lưu trữ trên IS này không riêng tư, phải chịu sự giám sát, đánh chặn và tìm kiếm thông thường và có thể được tiết lộ hoặc sử dụng cho bất kỳ mục đích được ủy quyền của USG. IS này bao gồm các biện pháp bảo mật (ví dụ: kiểm soát xác thực và kiểm soát truy cập) để bảo vệ lợi ích của USG - không phải vì lợi ích cá nhân hoặc quyền riêng tư của bạn. " Việc sử dụng các hệ thống này thường được bao phủ bởi một thỏa thuận đã ký quy định giống nhau. Chi tiết chính là chủ sở hữu của hệ thống đang tự bảo vệ mình trước bạn.

— Randall

Đó là một trong nhiều điểm khác biệt giữa Mỹ và Châu Âu. Các điều khoản @Randall trích dẫn ở trên là bất hợp pháp ở hầu hết các nước châu Âu.

— Aileron79

Các thuật ngữ tôi trích dẫn là không đầy đủ, các điều khoản khác liệt kê các hoạt động rõ ràng không được theo dõi. Tôi không thể tìm thấy bất kỳ tài liệu tham khảo nào nói rằng các nhà tuyển dụng châu Âu không thể đưa ra các điều kiện tiên quyết như vậy để sử dụng máy tính của họ (Tôi làm việc cho một công ty hoạt động ở châu Âu, thiết lập các quy trình giám sát như vậy, mặc dù tôi làm việc cho một bộ phận không kinh doanh Châu Âu), nhưng có thể tìm thấy các tài liệu tham khảo cho thấy các điều khoản đó không phải là bất hợp pháp miễn là chúng rõ ràng và minh bạch.

— Randall

9

Tôi nghĩ rằng câu hỏi này sẽ phù hợp hơn cho security.stackexchange.com trong đó chủ đề của MITM được thảo luận trong nhiều câu hỏi. Nhưng dù sao:

Xác thực chứng chỉ máy chủ chỉ được thực hiện tại máy khách và không thể chuyển bằng cách nào đó đến máy chủ vì điểm xác thực chứng chỉ tại máy khách là khách hàng cần đảm bảo rằng nó đang nói chuyện với đúng máy chủ và không thể tin tưởng vào máy chủ (không tin cậy) máy chủ để đưa ra quyết định này cho khách hàng.

Trong trường hợp SSL chặn, máy khách TLS từ góc độ của máy chủ là tường lửa / AV chặn SSL. Do đó, vấn đề ở phía máy chủ là phát hiện xem nó có đang nói chuyện với máy khách dự kiến (trình duyệt) hay không (tường lửa / AV). Cách an toàn nhất để làm điều này là sử dụng chứng chỉ ứng dụng khách để xác thực ứng dụng khách - và trên thực tế, việc chặn SSL sẽ không hoạt động nếu xác thực ứng dụng khách được sử dụng, tức là bắt tay TLS sẽ thất bại do MITM không thể cung cấp chứng chỉ ứng dụng khách dự kiến.

Chỉ, chứng chỉ khách hàng hiếm khi được sử dụng. Ngoài ra, bắt tay TLS không thành công sẽ không có nghĩa là máy khách có thể giao tiếp với máy chủ mà không bị chặn SSL nhưng máy khách hoàn toàn không thể giao tiếp với máy chủ. Một cách khác là sử dụng một số phương pháp phỏng đoán để phát hiện loại ứng dụng khách TLS dựa trên dấu vân tay của bắt tay TLS, tức là loại và thứ tự mật mã, sử dụng các tiện ích mở rộng cụ thể ... Trong lý thuyết, một proxy chặn SSL có thể mô phỏng bản gốc ClientHello hoàn toàn không. Xem thêm Phát hiện người trung gian ở phía máy chủ để tìm HTTPS hoặc phần III Giải pháp thực hiện TLS trong Tác động bảo mật của đánh chặn HTTPS .

— Steffen Ullrich
nguồn

14

Đối với tôi, dường như nhà tuyển dụng sử dụng vị trí ưu việt của mình để theo dõi lưu lượng SSL của nhân viên. Đối với tôi, điều này làm cho toàn bộ khái niệm về SSL không đáng tin cậy

Vấn đề không nằm ở khái niệm SSL cũng như trong triển khai kỹ thuật, mà là ai đó có toàn quyền kiểm soát một điểm cuối của kết nối, tức là máy trạm của bạn.
Đó là gốc rễ của rủi ro bảo mật thực tế ...

Từ góc độ bảo mật, máy trạm của bạn bị xâm phạm, phá vỡ chuỗi tin cậy mà trong các trường hợp thông thường sẽ ngăn MITM thành công.

Làm thế nào tôi có thể xác nhận chuỗi tin cậy ở phía máy chủ?

Bạn không thể. Điều đó được thực hiện phía khách hàng.

Tùy thuộc vào trường hợp sử dụng của bạn, những gì bạn có thể làm là RFC 7469 Ghim khóa công khai HTTP trong đó bạn đã gửi một tiêu đề bổ sung cho khách hàng với một danh sách (băm) chứng chỉ SSL thực tế của bạn hoặc CA mà bạn sử dụng.

— HBruijn
nguồn

4

HPKP sẽ không giúp ích vì nó sẽ bị các trình duyệt bỏ qua nếu chứng chỉ được ký bởi một CA được thêm vào rõ ràng. Điều này được thực hiện đặc biệt để cho phép chặn bởi SSL bởi một bên đáng tin cậy, tức là tường lửa của công ty hoặc AV máy tính để bàn cục bộ (nhiều người thực hiện chặn SSL).

— Steffen Ullrich

2

Bạn hoàn toàn chính xác ở đó: §2.6 từ RFC: "Có thể chấp nhận cho phép vô hiệu hóa Ghim đối với một số Máy chủ theo chính sách địa phương. một neo tin cậy do người dùng định nghĩa, thay vì một neo tin cậy được tích hợp vào UA (hoặc nền tảng cơ bản). "

— HBruijn

3

Đó là cách sai. Không phải máy chủ kiểm tra chuỗi tin cậy. Đó là Khách hàng. Vì vậy, lý do tại sao công ty sử dụng cách này là để bảo đảm an toàn cho công ty và kiểm tra những gì nhân viên đang làm trong thời gian làm việc của mình.

— beli3ver
nguồn

Vâng, vâng, tôi biết rằng điều này có lẽ không thể được ngăn chặn ở phía máy chủ. Tuy nhiên, một số JS phía máy khách cũng có thể bị lừa. BTW, gián điệp nhân viên là bất hợp pháp ở hầu hết các nước châu Âu. Là một nhà điều hành trang web, tôi muốn ngăn khách hàng của mình bị lừa, do đó tôi tự hỏi liệu có cách nào tôi có thể xác nhận chuỗi tin cậy một cách an toàn không.

— Aileron79

Có lẽ nó không được phép. Nhưng hầu hết các công ty không theo dõi nhân viên, họ chỉ muốn bảo mật mạng công ty và hầu hết các trình quét web hoặc trình quét phải phá vỡ kết nối SSL để kiểm tra điều này. Vì vậy, đây là một người đàn ông hợp pháp trong cuộc tấn công giữa

— beli3ver

Tôi hiểu quan điểm của bạn. Tuy nhiên, câu hỏi này là về cách tôi có thể đảm bảo kết nối HTTPS được mã hóa từ đầu đến cuối. Thiết lập mà tôi mô tả ở trên rất phổ biến trong môi trường công ty, nhưng kiểu tấn công tương tự có thể được sử dụng bởi các chàng trai ghen tuông để theo dõi bạn gái của họ hoặc bởi chủ nhà chặn giao thông của người thuê nhà. Những người này vẫn cần được lừa để cài đặt chứng chỉ, nhưng đó là phần dễ dàng. Tuy nhiên, điều này là bất hợp pháp - và tôi vẫn tự hỏi liệu có cách nào tôi có thể đảm bảo kết nối HTTPS thực sự được mã hóa e2e hay không.

— Aileron79

3

Đó là không thể. Khi chứng chỉ gốc đã được thay đổi trên máy khách, bạn không có cách nào để kiểm tra nó. Máy chủ không thực hiện kiểm tra, khách hàng thực hiện kiểm tra.

— beli3ver

3

Bạn COULD (loại), nhưng câu hỏi thực sự là liệu bạn NÊN .

Nhưng hãy cẩn thận, không có gì đơn giản bằng việc thay đổi một lá cờ trong apache.conf.

Ngoài ra, vì "kẻ tấn công" (ví dụ: chủ nhân) điều khiển máy khách, họ luôn có thể ngăn chặn nỗ lực của bạn nếu họ có xu hướng đầu tư đủ nỗ lực (về mặt sáng sủa, trừ khi bạn là con cá rất lớn, rất có thể họ không nghiêng, vì vậy bạn sẽ hoàn thành mục tiêu của mình rằng người dùng của bạn sẽ không thể kết nối với bạn trừ khi nó an toàn))

bạn có thể thực hiện lại TLS trong javascript và kiểm tra xem nếu chứng chỉ mà máy khách được kết nối là chứng chỉ của trang web của bạn.
nếu bạn may mắn , người dùng có thể đang sử dụng trình duyệt nơi Javascript phía máy khách có thể nhận thông tin về chứng chỉ từ xa được sử dụng (và do đó dễ dàng xác minh nó với giá trị mã hóa của chứng chỉ máy chủ của bạn).
bạn có thể sử dụng JavaScript để chạy mã hóa tùy chỉnh của mình . Vì vậy, ngay cả khi TLS MiTM độc ác của công ty thành công, nó vẫn không cho phép nó truy cập vào dữ liệu của bạn. Tất nhiên, nếu có đủ sự quan tâm (và vì họ kiểm soát khách hàng), họ có thể nhanh chóng thay thế javascript an toàn của bạn bằng chính họ cũng ghi nhật ký (hoặc thay đổi) tất cả thông tin đang truyền.

Ngoài ra, do các doanh nghiệp sử dụng proxy TLS MiTM cũng thường điều khiển hoàn toàn máy khách, họ có thể dễ dàng cài đặt màn hình và keylogger để ghi lại video mọi thứ người dùng nhìn thấy và ghi lại tất cả các lần nhấn phím (và chuyển động chuột) mà người dùng gõ. Như bạn có thể thấy, khi kẻ tấn công là khách hàng, không có cách nào an toàn tuyệt đối để đánh lừa anh ta. Đây thực sự chỉ là một câu hỏi họ sẽ bận tâm đến mức nào ... Và một số giải pháp ở trên có thể đủ tốt cho bạn.

— Matija Nalis
nguồn

" Bạn có thể thực hiện lại TLS trong javascript " Thế nào? Ở đâu?

— tò mò

@cquilguy rằng văn bản qouted là một liên kết - nhấp vào nó, và nó sẽ dẫn bạn đến một câu hỏi và câu trả lời khác, và cuối cùng đến dự án

— Digitalbazaar

Vì vậy, khi nào nó có thể sử dụng? Vì mục đích gì?

— tò mò

@cquilguy trong số nhiều thứ khác, đặc biệt là cho các mục đích được hỏi trong câu hỏi Serverfault này. Khi bạn có TLS JS riêng chạy trên máy khách, JS máy khách đó sẽ biết chính xác máy chủ TLS nào mà máy khách đã được kết nối (và đó là khóa chung). Sau đó, bạn có thể so sánh khóa chung đó với khóa chung của máy chủ được ủy quyền (cũng được mã hóa cứng trong mã JS của bạn) và nếu bạn sẽ biết liệu chúng có giống nhau không. Nếu chúng không giống nhau, kết nối của bạn đã bị MiTM chiếm quyền điều khiển.

— Matija Nalis