Tham gia Đăng nhập
Điểm:1
avatar Crypto

Thông báo kết thúc máy khách TLS 1.2

lá cờ pk
Aiin Zul

Tôi đang làm việc trên TLS1.2 trên bộ mật mã ECDHE_ECDSA_AES_128_CBC_SHA256. Tôi hiện đang ở giai đoạn gửi tin nhắn được mã hóa cho máy khách, nơi tôi luôn gặp lỗi trên Wireshark từ máy chủ nói rằng Gây tử vong, Mô tả: Lỗi bắt tay. Vì vậy, từ những gì tôi đã thực hiện nghiên cứu của mình, việc chứa thông báo kết thúc của khách hàng này giả sử trải qua các bước sau:

  1. 1 byte kiểu bắt tay: kết thúc = 0x14
  2. 3 byte dữ liệu_verify_length = 12
  3. 12 byte verify_data
  4. 16 byte này từ các bước 1),2) và 3) được chuyển qua hmac_sha256 và cho và tạo ra 32 byte băm. Ai đó có thể xác nhận cho tôi các đầu vào? 5) 32 byte được đặt trước 16 byte từ các bước 1), 2) và 3) và cung cấp tổng cộng 48 byte trước khi đệm
  5. Chúng tôi đã thêm độ dài 1 byte của phần đệm và 15 byte phần đệm của 0x0F và cung cấp tổng cộng 64 byte
  6. 64 byte sau đó được mã hóa bằng máy khách IV và khóa mã hóa máy khách
  7. 64 byte được đặt trước 16 byte IV trước khi gửi đến máy chủ

Ai đó có thể xác minh tất cả các bước và sửa lỗi cho tôi nếu tôi sai vì tôi liên tục gặp lỗi bắt tay vào thời điểm này.

Cảm ơn bạn trước!

60
0 + 0
aes
Điểm:2
dave_thompson_085 avatar Crypto
lá cờ cn
dave_thompson_085

Như đã nêu trong câu hỏi năm 2015 này cộng với câu trả lời của tôi mà dường như bạn đã không đọc ngay cả khi nhận xét về câu trả lời khác, TLS <=1.2 HMAC được tính trên:

  • các ghi số thứ tự, loại, phiên bản và độ dài: hex 00 00 00 00 00 00 00 00 16 03 03 00 10

  • cộng với Hoàn thành thông điệp mà bạn có chính xác là loại 1 byte = 14, độ dài 3 byte = 00 00 0C và 12 byte 'verify_data'

sử dụng khóa MAC của máy khách (từ quy trình tạo khóa).

Bạn có phần tiếp theo đúng: bạn mã hóa CBC phần thân bản ghi (chính xác là thông báo bắt tay) cộng với HMAC cộng với phần đệm (16 lần 0F) và thêm IV 16 byte được sử dụng (không thể đoán trước, thường là ngẫu nhiên). Và chuẩn bị cho điều đó tiêu đề bản ghi loại = 16, phiên bản = 03 03, độ dài = 00 50.

Lưu ý rằng ngoài việc bản ghi được định dạng, HMACed và mã hóa chính xác, verify_data Trong thông báo phải chính xác và IME, hầu hết mọi người gặp nhiều khó khăn hơn khi hiểu đúng điều đó hơn là xử lý bản ghi.

Thẩm quyền giải quyết: RFC5246 6.2.3.1 (và 6.2.3.2 cho mã hóa CBC)

0 + 0
lá cờ pk
Aiin Zul
Tổng số byte đầu vào cho hmac có phải là 29 byte theo bài đăng của bạn không: hex 00 00 00 00 00 00 00 00 16 03 03 00 10 + 16 byte (loại 1 byte + độ dài 3 byte + dữ liệu xác minh 12 byte)?
0
Hồi đáp
lá cờ pk
Aiin Zul
Tôi đã sửa lỗi đầu vào hmac của mình theo bài đăng của bạn. Nhưng tôi vẫn gặp sự cố bắt tay không thành công. Chà, hãy bắt đầu từ cách tôi đã làm để tạo verify_data : 1) hàm băm của tất cả thông báo bắt tay trước đó: SHA256(all_handshake_messages) 2) Sau đó, tôi đã thực hiện prf(maseter_secret, "client_finished", SHA256(all_handshake_messages)) Chúng tạo ra 12 byte verify_data Sau đó, tôi nối dữ liệu ở bước 3) với dữ liệu ở bước 1) và 2) trong bài đăng đầu tiên của mình, tôi đã thực hiện các bước còn lại. Điều gì có thể gây ra lỗi Bắt tay?
0
Hồi đáp
lá cờ VietNam
Phan Văn Trường
Câu hỏi này là trong các ngôn ngữ khác:

Đă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.