Đối với một chương trình tôi đang viết, tôi muốn sử dụng TLS (hoặc một cái gì đó tương tự) để đóng gói giao thức của ứng dụng của tôi. Điều này sẽ giảm thiểu cả số lượng công việc tôi phải làm cũng như số lỗ hổng mà tôi có thể vô tình tạo ra.Mật mã và xác thực thông qua TLS với Web of Trust trong Java
Chương trình của tôi được thiết kế ngang hàng mặc dù một hoặc nhiều máy chủ cung cấp một số dịch vụ để giúp một người dùng định vị một dịch vụ khác (nó đăng ký địa chỉ IP/cổng combo) nhưng làm ít. Tôi muốn làm cho hệ thống này có khả năng chịu lỗi, vì vậy việc các máy chủ này hoạt động như một Tổ chức phát hành chứng chỉ là không thể chấp nhận được vì sự thỏa hiệp của máy chủ hoặc khóa của máy chủ sẽ ảnh hưởng đến quá nhiều người dùng. Do đó tôi có kế hoạch sử dụng một Web of Trust.
Vấn đề chính khi sử dụng TLS là đặc tả TLS 1.2 ban đầu (RFC 5246) không cung cấp cho việc sử dụng chứng chỉ OpenPGP. Nó có vẻ là rất trung tâm x.509. RFC 6091, mà lỗi thời RFC 5081 và mở rộng RFC 5246, làm cho các điều khoản cho một phần mở rộng cho TLS thực hiện những gì tôi muốn. Vấn đề là tôi không nghĩ rằng BouncyCastle thực hiện phần mở rộng này và tôi không thể tìm thấy một thư viện mã hóa Java nào. Tôi cũng không muốn viết của riêng mình/đóng góp cho BC bởi vì tôi thực sự xấu không phạm sai lầm và tôi cũng rất lười biếng.
Một vấn đề khác là BouncyCastle cung cấp "một API TLS trọng lượng nhẹ phía máy khách" nhưng vì phần mềm này là P2P, API phía máy chủ cũng cần thiết để tôi có thể sử dụng TLS bằng cách làm cho nó tin rằng bắt nguồn từ kết nối là máy khách. Tôi khá chắc chắn rằng một khi cái bắt tay hoàn thành thì nó giống nhau.
Câu hỏi: Có cách nào để tôi vẫn có thể sử dụng TLS (mà tôi rất nghi ngờ) không? Có một giao thức như TLS được thiết kế cho P2P hay ít nhất có thể hoạt động theo cách này (như tôi tin TLS có thể), nhưng có thể làm việc với chứng chỉ OpenPGP? Nếu không phải vậy, tôi có nên theo đuổi ý tưởng được giải thích trong this question và triển khai lớp của riêng tôi lấy khái niệm từ TLS không?
Liên kết đến RFC: RFC 5246 và RFC 6091
Rất tiếc, điều này không đúng. Việc phân tích chứng chỉ là bắt buộc đối với việc bắt tay TLS. Đây là lý do cho phần mở rộng RFC 6091 cho TLS. – Nikos
Thực ra tôi đã thực hiện các máy khách và máy chủ TLS không phân tích chứng chỉ. Vì vậy, nó là có thể. Khi máy khách nhận được chứng chỉ máy chủ, nó sẽ đưa các đốm màu vào một cuộc gọi lại bên ngoài để gửi lại khóa công khai để sử dụng - trong trường hợp của tôi, gọi lại đã giải thích các đốm màu như các chứng chỉ X.509 (mà nó đã phân tích cú pháp và xác thực), nhưng nó chắc chắn có thể giải thích cho họ bằng cách khác, hoặc thậm chí ném chúng đi và sử dụng một khóa công khai máy chủ hardcoded, đó là hợp lệ trong một số thiết lập. –
Thực tế là việc triển khai của bạn đã xử lý các chứng chỉ dưới dạng các đốm màu, nó không loại bỏ yêu cầu của TLS để phân tích cú pháp đó. Bạn chỉ cần ủy quyền nó cho một cuộc gọi lại, nhưng vẫn phân tích cú pháp phải được thực hiện để hoàn tất giao thức. – Nikos