2010-06-29 34 views
5

Chúng tôi đang tìm một giải pháp cho phép chúng tôi sử dụng HTTPS mà không cần mã hóa. Tại sao? Đây là câu chuyện:Sử dụng HTTPS trong Java mà không cần mã hóa

Sản phẩm của chúng tôi (được cài đặt tại khách hàng) kết nối với máy chủ của chúng tôi để tìm thông tin cập nhật, đăng thông tin, v.v. Chúng tôi muốn sản phẩm xác minh rằng nó được kết nối với máy chủ (và không phải là kẻ mạo danh) trước khi đăng dữ liệu. Chúng tôi cũng cần đảm bảo không có các cuộc tấn công trung gian (tức là nội dung phải được ký kết, v.v.). Tuy nhiên, khách hàng của chúng tôi yêu cầu họ có thể đánh hơi lưu lượng truy cập (Wireshark, tcpdump, v.v.) và xem toàn bộ nội dung của giao dịch. Điều này là vì lý do tuân thủ và bảo mật.

Sản phẩm của chúng tôi được viết bằng Java, nhân tiện.

Bất kỳ ý tưởng nào?

CẬP NHẬT: Vui lòng giải thích nếu tôi không sử dụng đúng biểu mẫu để trả lời câu trả lời, tôi khá mới trên trang web này.

Trước hết, cảm ơn bạn đã có câu trả lời nhanh chóng!

Lý do của chúng tôi để điều tra khả năng HTTPS là vì chúng tôi không muốn phát minh ra giao thức mới tại đây. Nó không chỉ là số lượng công việc mà còn là một thực tế rằng phát minh ra giao thức bảo mật của riêng bạn (ngay cả khi chỉ để ký) thường được coi là thực hành xấu. Chúng tôi đang cố gắng đạt được lợi thế của HTTPS trong việc xác thực máy chủ (điều quan trọng, máy chủ này cũng phục vụ mã thực thi có thể khá lớn - chúng tôi không muốn bất kỳ ai phân phối phần mềm độc hại hoặc DoSing khách hàng của chúng tôi với dữ liệu lớn chỉ sau khi nhận được toàn bộ điều sẽ hệ thống phát hiện ra nó là xấu) cũng như đảm bảo MITM không xảy ra (việc ký các bản thân các thông điệp). Chúng tôi không quan tâm nếu có ai evesdropes trên giao thông bởi vì nó không bao giờ chứa một cái gì đó được coi là bí mật. Hơn nữa, nó không nhất thiết cần phải dễ dàng để đọc các nội dung trong Wireshark, chỉ có thể để kiểm toán viên có thể làm điều đó.

@Nate Zaugg - không, đây không phải là trò đùa. Thật đáng ngạc nhiên khi các nhà cung cấp sử dụng HTTPS với mã hóa ngày hôm nay và không nhận được nhiều phản ứng dữ dội từ khách hàng với các vấn đề tuân thủ nghiêm ngặt.

@erickson - Giải pháp đầu tiên với bộ mã hóa NULL có vẻ thú vị, chúng tôi sẽ xem xét nó. Giải pháp thứ hai sẽ yêu cầu một bộ khóa cho mỗi khách hàng - không phải thứ chúng tôi muốn quản lý.

@ZZ Coder - ý bạn là với mật mã null, bạn sẽ không thể xem nội dung trong Wireshark?

+6

Đề xuất sửa lại câu hỏi, "Hiển thị lưu lượng truy cập HTTPS để đánh hơi/kiểm tra bảo mật". – Freiheit

Trả lời

9

Có SSL "ciphersuites" không có mã hóa và tất cả các phiên bản của nhà cung cấp Sun JSSE đều hỗ trợ SSL_RSA_WITH_NULL_SHA. Tuy nhiên, tất cả các dữ liệu ứng dụng vẫn được bao bọc trong các bản ghi SSL (để mang MAC cung cấp sự bảo vệ toàn vẹn, vv), vì vậy khi bạn nhìn vào nó trong Wireshark, bạn sẽ thấy các cấu trúc này. Ngoài ra, miễn là bạn không sử dụng Diffie-Hellman tạm thời (một trong số DHE_XXX ciphersuites), bạn có thể cung cấp cho Wireshark khóa riêng của máy chủ, và nó sẽ giải mã một phiên SSL. Trong khi đây là một số công việc phụ, nó không áp đặt bất kỳ yêu cầu bất thường nào trên máy chủ hoặc máy khách để hỗ trợ các mật mã không được mã hóa hiếm khi được sử dụng.

+3

Upvote cho giải pháp Wireshark. Lý tưởng nhất là nếu bạn làm điều này cho khách hàng này, hãy cung cấp cho họ khóa riêng của họ thay vì chia sẻ khóa riêng của máy chủ của bạn. Điều này đảm bảo rằng nếu khóa bị mất chỉ có khách hàng bị ảnh hưởng. – Freiheit

3

Nếu bạn chỉ cần ký tên, tại sao bạn không thể ký vào mỗi câu trả lời bằng khóa riêng (đặt chữ ký trong tiêu đề) và xác minh bằng khóa công khai trên máy khách, nhưng không sử dụng HTTPS? Vì vậy, miễn là khóa riêng của bạn vẫn bí mật và bạn chọn một thuật toán chữ ký thích hợp, điều này sẽ ngăn chặn giả mạo với cơ thể của phản ứng nhưng không giữ bí mật cơ thể đó.

+0

Đây là một ý tưởng hay, ngoại trừ yêu cầu xác minh danh tính máy chủ * trước khi đăng bất kỳ dữ liệu nào lên đó. Tuy nhiên, tôi không chắc liệu yêu cầu đó có hợp lý hay không, bởi vì thông thường bạn muốn xác minh danh tính để tránh rò rỉ bí mật cho một người đàn ông ở giữa; ở đây, nội dung không phải là riêng tư, vì vậy tôi không thấy tại sao nội dung lại quan trọng. – erickson

+0

@erickson: Bạn có thể đưa ra yêu cầu trống và yêu cầu máy chủ chỉ cần ký một phản hồi nhỏ không có dữ liệu quan trọng trong đó. –

+0

Nếu tôi đang theo đuổi tack này, tôi sẽ xem xét trả lời bằng một thông báo đã ký S/MIME nhiều phần. – erickson

0

Bạn có thể thử sử dụng mật mã NULL (1 và 2) nhưng hầu hết các máy chủ đều được cấu hình để không chấp nhận mật mã yếu. Tất nhiên, 2 mật mã này là yếu nhất.

Ngay cả khi tải trọng sẽ ở dạng văn bản rõ ràng, nó vẫn được gói bên trong khung SSL để giải mã gói phổ biến nhất không hoạt động.

1

Tôi đồng ý với @Jon Skeet - bạn không nên cố gắng sử dụng HTTPS bị tê liệt, thay vào đó bạn chỉ nên ký câu trả lời của mình. Bạn có thể xem một số tài liệu cho Amazon's S3 để có một ví dụ điển hình về mô hình bảo mật mạnh mẽ, mạnh mẽ và khá đơn giản.

Tóm lại, ý tưởng cơ bản là, có một số loại khóa bí mật, thêm nó và dấu thời gian vào thư của bạn và băm đó. Gửi băm và ngày (nhưng không phải là bí mật, rõ ràng) cùng với thông điệp của bạn đến máy chủ. Máy chủ của bạn sau đó kiểm tra xem ngày có đủ gần để tin tưởng không (nói 15 phút) và băm yêu cầu, ngày tháng và khóa bí mật mà nó có trong hồ sơ. Nếu nó nhận được cùng một băm, thì một tài nguyên đáng tin cậy đã tạo ra yêu cầu và máy chủ có thể tiến hành một cách an toàn.

Rõ ràng, điều này không an toàn với việc đánh hơi người ở giữa (mà bạn có vẻ ổn) nhưng nó sẽ ngăn không cho MITM thay đổi hoặc tạo ra các yêu cầu giả mạo.

0

cũng không nên mỗi khách hàng có khóa riêng biệt? nếu không thì máy chủ của bạn biết ai đang đăng? máy chủ không quan tâm đến bất kỳ người đàn ông nào ở giữa?

nếu mỗi khách hàng có khóa, như mật khẩu đơn giản, máy chủ biết, khóa có thể được sử dụng làm muối có hàm băm để ký yêu cầu/phản hồi.

Các vấn đề liên quan