Điểm:0

SSLv3 ServerKeyExchange Cấu trúc chữ ký không khớp

lá cờ pl

Tôi đang chơi với việc triển khai SSLv3 trong Go theo rfc6101.

Tôi có thể giải tuần tự hóa ServerKeyExchange cho đến ServerKeyExchange.signed_params.

Bộ mật mã là TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003).

Thuật toán chữ ký chứng chỉ: 1.2.840.113549.1.1.5 (sha1WithRSAEencryption).

Theo RFC, các cấu trúc sẽ trông như thế này:

        cấu trúc {
            chọn (KeyExchangeAlgorithm) {
                trường hợp diffie_hellman:
                    Thông số ServerDHParams;
                    Chữ ký đã ký_params;
                trường hợp rsa:
                    Thông số ServerRSAParams;
                    Chữ ký đã ký_params;
                trường hợp fortezza_kea:
                    Thông số ServerFortezzaParams;
            };
        } ServerKeyExchange;
        cấu trúc được ký điện tử {
            chọn (Thuật toán chữ ký) {
                trường hợp ẩn danh: struct { };
                trường hợp rsa:
                    mờ md5_hash[16];
                    sha_hash mờ [20];
                trường hợp dsa:
                    sha_hash mờ [20];
            };
        } Chữ ký;

nhưng tôi nhận được một phản hồi khác từ máy chủ:

nhập mô tả hình ảnh ở đây

Tôi đang thiếu gì?

Cảm ơn!

dave_thompson_085 avatar
lá cờ cn
**Không đồng ý với VtC là 'lập trình'**; mặc dù OP đang viết mã, Q không phải là về mã mà là về giao thức độc lập với bất kỳ triển khai nào và không thuộc về SO. Nó _is_ 'sử dụng' tiền điện tử thay vì bản thân tiền điện tử và có thể tốt hơn về bảo mật.SX, nhưng tôi gọi đó là đường biên giới.
Điểm:0
lá cờ cn

Khoảng 10 dòng trên phần bạn trích dẫn, có

        cấu trúc {
            rsa_modulus mờ đục<1..2^16-1>;
            rsa_exponent mờ đục<1..2^16-1>;
        } Máy chủRSAParams;

vậy trường hợp =rsa (thực tế chỉ dành cho rsa_export) của Máy chủKeyExchange thực sự là:

        Máy chủRSAPThông số:
            rsa_modulus -- mờ đục (số nguyên không dấu bigendian thực sự)
            rsa_exponent -- giống như vậy
        Chữ ký -- ditto 

nhưng cấu trúc này không ảnh hưởng đến mã hóa, chỉ chứa ba giá trị 'lá' và bất kỳ giải mã nào bạn đang xem (Wireshark?) Không cần phân biệt hai cấp độ ở đây.

Ghi chú cấu trúc chữ ký điện tử ... Chữ ký không có nghĩa là hai giá trị băm (md5 và sha1) được chứa trong thông báo; thay vào đó, chúng là đầu vào cho thuật toán tạo chữ ký có thể áp dụng, trong trường hợp này là RSA 'khối loại 1' được xác định trong PKCS1v1 (hiện được đổi tên thành RSASSA-PKCS1-v1_5 trong PKCS1v2) và đầu ra của thuật toán chữ ký, đối với RSA, một số nguyên duy nhất được mã hóa dưới dạng độ dài cố định không dấu bigendian (xem 'I2OSP' trong bất kỳ phiên bản nào của PKCS1), là nội dung được đặt trong thông báo, với tiền tố độ dài 2 byte, giống như nó đã được khai báo mờ đục<?..2^16-1> mặc dù tôi không thấy điều này được nêu trong RFC6101; TLS1.0 RFC2246 et succ nêu rõ điều đó trong 4.7.

(Bạn có thể muốn xem thêm/tất cả RFC2246; ngoại trừ PRF và dẫn xuất khóa, một số mã cảnh báo và bộ mật mã, việc bổ sung các tiện ích mở rộng (trong đó Thỏa thuận lại an toàn RFC5746 trở nên khá bắt buộc) và tất nhiên là số phiên bản, để điều tốt nhất trong trí nhớ của tôi là TLS1.0 về mặt kỹ thuật giống như SSL3, nhưng tài liệu kỹ lưỡng hơn, có thể là do trải qua vòng găng tay IETF^W process.)

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.