Tìm hiểu giao thức DTLS

MỤC LỤC2LỜI MỞ ĐẦU3PHẦN I: GIỚI THIỆU CHUNG41. Hoàn cảnh ra đời.42. Cấu trúc giao thức DTLS.53. Mô hình sử dụng.5PHẦN II: HOẠT ĐỘNG CỦA GIAO THỨC61. Tổng quan.61.1. Truyền thông vô cảm.61.2. Cung cấp độ tin cậy cho Handshake.61.2.1. Mất gói tin.61.2.2. Sắp xếp lại.71.2.3. Kích thước thông điệp.71.3. Phát hiện sự phát lại.72. Sự khác biệt với TLS.82.1. Lớp bản ghi.82.1.1. Transport Layer Mapping92.1.1.1. Tìm hiểu về PMTU.92.1.2. Bảo vệ khối bản ghi102.1.2.1. MAC102.1.2.2. Luồng mật mã chuẩn hoặc NULL102.1.2.3. Khối mật mã112.1.2.4. Bộ mật mã mới112.1.2.5. Chống truyền lại112.2. Giao thức Handshake DTLS.112.2.1. Đối phó với denial of service.122.2.2. Định dạng thông điệp handshake.142.2.3. Phân mảnh thông điệp và tái lắp ráp.152.2.4. Timeout và truyền lại.152.2.4.1. Giá trị bộ hẹn giờ.182.2.5. ChangeCipherSpec.182.2.6. Finished Messages.192.2.7. Alert Messages.192.3. Tóm tắt các cú pháp mới.192.3.1. Record Layer192.3.2. Handshake Protocol203. chú ý bảo mật204. Mô phỏng hoạt động của dtls để kiểm tra handshake:………………………………………………………………...…21KẾT LUẬN21

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG - o o - BÁO CÁO BÀI TẬP LỚN GIAO THỨC DTLS Học phần: Mạng máy tính Mã lớp: Giáo viên hướng dẫn: Sinh viên thực hiện: Hà Nội-2018 MỤC LỤC MỤC LỤC LỜI MỞ ĐẦU PHẦN I: GIỚI THIỆU CHUNG Hoàn cảnh đời Cấu trúc giao thức DTLS Mơ hình sử dụng .5 PHẦN II: HOẠT ĐỘNG CỦA GIAO THỨC Tổng quan .6 1.1 Truyền thông vô cảm 1.2 Cung cấp độ tin cậy cho Handshake 1.2.1 Mất gói tin 1.2.2 Sắp xếp lại 1.2.3 Kích thước thơng điệp 1.3 Phát phát lại Sự khác biệt với TLS 2.1 Lớp ghi 2.1.1 Transport Layer Mapping 2.1.1.1 Tìm hiểu PMTU 2.1.2 Bảo vệ khối ghi 10 2.1.2.1 MAC 10 2.1.2.2 Luồng mật mã chuẩn NULL .10 2.1.2.3 Khối mật mã 11 2.1.2.4 Bộ mật mã 11 2.1.2.5 Chống truyền lại 11 2.2 Giao thức Handshake DTLS 11 2.2.1 Đối phó với denial of service 12 2.2.2 Định dạng thông điệp handshake 14 2.2.3 Phân mảnh thông điệp tái lắp ráp 15 2.2.4 Timeout truyền lại 15 2.2.4.1 Giá trị hẹn 18 2.2.5 ChangeCipherSpec 18 2.2.6 Finished Messages 19 2.2.7 Alert Messages 19 2.3 Tóm tắt cú pháp 19 2.3.1 Record Layer 19 2.3.2 Handshake Protocol 20 ý bảo mật 20 Mô hoạt động dtls để kiểm tra handshake:……………………………………………………………… …21 KẾT LUẬN .21 TÀI LIỆU THAM KHẢO 25 LỜI MỞ ĐẦU Sự phát triển công nghệ ngày đặt yêu cầu mang tính cấp thiết để đáp ứng nhu cầu cập nhật ngày giờ, cần phải đưa giải pháp phù hợp hiệu Toàn cầu hóa cơng xây dựng ngành cơng nghiệp 4.0 sở cho đời phát minh Trong lĩnh vực truyền thông mạng máy tính, số lượng giao thức sử dụng mạng máy tính đời tăng cách nhanh chóng Trên sở giao thức cũ, hai giao thức TCP UDP tỏ hiệu hết cho mục đích cụ thể tầng vận chuyển Tuy nhiên, khác biệt hai giao thức mà phương thức bảo mật cho TCP thiếu hiệu UDP Vấn đề đặt cần cải tiến cách linh hoạt tạo giao thức bảo mật đáp ứng giao thức UDP sở giao thức bảo mật TCP Điều tận dụng ưu điểm hai giao thức tăng hiệu sử dụng Trong báo cáo nhóm em trình bày giao thức Datagram Transport Layer Security (DTLS), phát triển dựa giao thức Transport Layer Security (TLS) sử dụng UDP PHẦN I: GIỚI THIỆU CHUNG HOÀN CẢNH RA ĐỜI TLS giao thức triển khai rộng rãi cho việc bảo mật truyền tải mạng Nó sử dụng cho việc bảo vệ truyền tải web cho giao thức email imap pop Lợi ích TLS cung cấp kênh kết nối minh bạch-kênh định hướng Vì dễ để bảo vệ giao thức ứng dụng cách chèn TLS lớp ứng dụng lớp truyền tải mơ hình OSI Tuy nhiên, TLS phải chạy thông qua kênh vận chuyển đáng tin cậy (thường TCP) Cho nên sử dụng để bảo đảm việc truyền tải gói tin khơng đáng tin cậy Trong vài năm trở lại đây, ngày có nhiều giao thức lớp ứng dụng thiết kế cho việc truyền tải UDP Một giao thức cụ thể Session Initiation Protocol (SIP) giao thức game điện tử ngày phổ biến (lưu ý SIP chạy TCP UDP có nhiều tình dùng UDP thích hợp hơn) Gần đây, nhà thiết kế ứng dụng phải đối mặt với nhiều lựa chọn khơng đạt u cầu Đầu tiên, họ sử dụng giao thức IPsec Tuy nhiên, số lý do, IPsec thích hợp cho số ứng dụng Thứ hai, họ thiết kế giao thức bảo mật lớp ứng dụng SIP sử dụng phần S-MIME để đảm bảo việc truyền tải Thật khơng may, giao thức bảo mật lớp ứng dụng thường cung cấp đặc tính bảo mật cao cấp, ví dụ bảo mật end-to-end trường hợp S-MIME, chúng thường đòi hỏi nhiều cơng sức để thiết kế lại sử dụng để chạy giao thức TLS Trong nhiều trường hợp, cách tốt để bảo vệ ứng dụng client/server nên sử dụng TLS Tuy nhiên, yêu cầu ngữ nghĩa gói tin tự động cấm việc sử dụng giao thức TLS Do biến thể tương thích TLS, kỳ vọng Tài liệu mô tả chi tiết giao thức DTLS Datagram Transport Layer Security DTLS thiết kế giống với TLS, giảm thiểu phát minh bảo mật tăng việc tái sử dụng code sở vật chất CẤU TRÚC GIAO THỨC DTLS MƠ HÌNH SỬ DỤNG Giao thức DTLS thiết kế để bảo vệ liệu giao tiếp ứng dụng Nó thiết kế để chạy khơng gian ứng dụng, với việc khơng có yêu cầu sửa đổi bên Việc truyền tải gói tin khơng u cầu cung cấp đáng tin cậy theo thứ tự phân phối liệu Giao thức DTLS trì thuộc tính cho liệu tải trọng Các ứng dụng truyền phát trực tuyến, gọi điện qua internet game online sử dụng truyền tải gói tin để giao tiếp chậm trễ - tính chất nhạy cảm liệu vận chuyển Hành vi ứng dụng không thay đổi giao thức DTLS sử dụng để an tồn giao tiếp giao thức DTLS khơng bù đắp cho lượng liệu bị xếp lại Nguyên lý thiết kế DTLS xây dựng “TLS gói tin” Lý TLS sử dụng trực tiếp môi trường gói tin, đơn giản gói bị xếp lại Bản chất TLS tự xử lý trường hợp không đáng tin cậy này, việc triển khai TLS bị hỏng lưu trữ lại truyền tải gói tin Mục đích DTLS tạo thay đổi tối thiểu để yêu cầu TLS khắc phục cố Đến mức tối đa, DTLS giống với TLS Bất cần tạo chế mới, cố gắng làm theo cách bảo tồn lại cấu trúc TLS PHẦN II: HOẠT ĐỘNG CỦA GIAO THỨC TỔNG QUAN Sự không đáng tin cậy tạo vấn đề cho TLS hai mức: - Lớp mã hóa truyền tải TLS khơng cho phép việc giải mã độc lập ghi riêng rẽ Nếu ghi N khơng nhận ghi N+1 giải mã - Lớp TLS handshake giả định thông điệp handshake vận chuyển cách đáng tin cậy bị hỏng thông điệp handshake bị Phần mô tả cách DTLS giải vấn đề 1.1 Truyền thông vô cảm Ở lớp mã hóa truyền tải TLS (được gọi Record Layer TLS), ghi không độc lập với Có hai loại phụ thuộc ghi: - Ngữ cảnh mật mã (trạng thái CBC, luồng khóa mật mã dòng) nối với ghi - Chống phát lại bảo vệ thứ tự thơng điệp cung cấp khung MAC có chứa Sequence Numbers Sequence Numbers ẩn ghi Cách giải cho hai vấn đề đơn giản phổ biến IPsec ESP: thêm trạng thái rõ ràng vào ghi TLS 1.1 thêm trạng thái CBC rõ ràng vào ghi DTLS kế thừa chế thêm thành phần Sequence Numbers vào ghi 1.2 Cung cấp độ tin cậy cho Handshake Cơ chế TLS chế sử dụng mật mã khóa Thông điệp phải chuyển nhận lại trình tự định, trình tự khác gây lỗi Rõ ràng, điều không tương thích với việc yêu cầu phát lại bị thơng điệp Hơn thơng điệp handshake TLS có kích thước lớn gói liệu gửi, gây vấn đề phân mảnh DTLS phải cung cấp giải pháp cho vấn đề 1.2.1 Mất gói tin DTLS sử dụng hẹn truyền lại để xử lý việc gói tin Sơ đồ minh họa khái niệm bản, sử dụng giai đoạn DTLS handshake: Client -ClientHello > Server X< HelloVerifyRequest (lost) [Timer Expires] ClientHello (retransmit) > Sau client gửi thơng điệp Clienthello, đợi HelloVerifyRequest từ Server, nhiên thông điệp bị thì Client biết hai thơng điệp ClientHello HelloVerifyRequest bị truyền lại Khi server nhận thơng điệp truyền lại truyền lại Server trì hẹn truyền lại, thực truyền lại đếm chạy hết Lưu ý: Timeout chế truyền lại không áp dụng cho tin HelloVerifyRequest u cầu trạng thái server 1.2.2 Sắp xếp lại Trong DTLS thông điệp handshake phát cho Sequence number riêng Khi bên nhận thơng điệp handshake, nhanh chóng xác định có phải thơng điệp mong đợi hay khơng Nếu đúng, xử lý thơng điệp Ngược lại, thơng điệp đưa vào hàng đợi để xử lý sau nhận tất thơng điệp trước 1.2.3 Kích thước thơng điệp Thơng điệp handshake TLS DTLS lớn, lý thuyết lên tới 2^24-1 bytes, thực tế hàng kilobytes Ngược lại gói liệu UDP thường nhỏ 1500 bytes Nếu phân mảnh không mong đợi Để bù đắp cho hạn chế này, thông điệp handshake DTLS cần phân mảnh thành số ghi DTLS Mỗi thông điệp DTLS handshake bao gồm offset cảu mảnh độ dài mảnh Do đó, bên nhận sở hữu tất bytes thông điệp handshake ghép lại thành thơng điệp ban đầu chưa bị phân mảnh 1.3 Phát phát lại DTLS hỗ trợ phát phát lại ghi Kỹ thuật sử dụng giống với IPsec AH/ESP, cách trì cửa sổ bitmap ghi nhận Các ghi cũ để phù hợp với cửa sổ ghi nhận trước bị loại bỏ Đặc tính phát phát lại tùy chọn, trùng lặp gói tin khơng lúc gây nguy hiểm dẫn đến lỗi định tuyến Các ứng dụng phát gói tin trùng lặp điều chỉnh chiến lược truyền tải liệu cho phù hợp SỰ KHÁC BIỆT VỚI TLS Như đề cập phần 1, DTLS giống với TLS Vì thay cho việc giới thiệu DTLS giao thức giới thiệu phiên TLS 1.1 Ở chỗ không khác biệt cách rõ ràng, DTLS giống hệt TLS 1.1 2.1 Lớp ghi Lớp ghi DTLS giống với TLS 1.1 Sự thay đổi có bao gồm Sequence number ghi Sequence number cho phép bên nhận xác thực xác khung MAC TLS Khn dạng ghi DTLS mô tả sau: struct { ContentType type; ProtocolVersion version; uint16 epoch; // New field uint48 sequence_number; // New field uint16 length; opaque fragment[DTLSPlaintext.length]; } DTLSPlaintext; Trong đó: - type: tương đương với kiểu thuộc tính ghi TLS 1.1 -version: phiên giao thức sử dụng -epoch: giá trị biến đếm tăng lên trạng thái mật mã thay đổi - sequence number: sequence number ghi -length: độ dài ghi TLS 1.1, không nên vượt 2^14 bytes - fragment: giống với ghi TLS 1.1 DTLS sử dụng sequence number tường minh thay ngầm định Được gắn trường sequence number ghi Với TLS, sequence number đặt sau thông điệp ChangeCipherSpec gửi Nếu vài handshake thực cách nhau, có nhiều ghi bị trùng sequence number khác trạng thái mật mã Trường epoch cho phép bên nhận phân biệt gói Số epoch ban đầu tăng sau lần thông điệp ChangeCipherSpec gửi Để đảm bảo cặp sequence-epoch nhất, q trình thực khơng cho phép giá trị epoch giống sử dụng hai lần thời gian tồn phân đoạn Thực tế, trình thực TLS thực lại handshake vấn đề đáng quan tâm 2.1.1 Transport Layer Mapping Mỗi ghi DTLS phải phù hợp với gói liệu Để tránh phân mảnh IP, triển khai DTLS nên xác định rõ MTU gửi ghi nhỏ MTU Sự triển khai DTLS nên cung cấp cách cho ứng dụng để xác định giá trị PMTU (hoặc luân phiên, kích cỡ tối đa gói liệu ứng dụng PMTU trừ chi phí ghi DTLS) Nếu ứng dụng cố gửi ghi lớn MTU, việc triển khai DTLS gặp lỗi, tránh gửi gói bị phân mảnh Lưu ý không giống IPsec, ghi DTLS không bao gồm số liên kết nhận dạng Các ứng dụng phải xếp để ghép nối liên kết Với UDP, thực với số host/port Nhiều ghi DTLS đặt gói tin Chúng mã hóa đơn giản cách liên tục Khung ghi DTLS vừa đủ để xác định ranh giới chúng Lưu ý rằng, bytes trọng tải gói tin phải phần đầu ghi Các ghi khơng thể mở rộng gói liệu Một số phương tiện, DCCP cung cấp sequence number riêng chúng Khi thực qua phương tiện đó, DTLS sequence number phương tiện định Mặc dù điều phát sinh số lượng nhỏ thứ không hiệu quả, lớp vận chuyển sequence number DTLS phục vụ mục đích khác nhau, để đơn giản khái niệm, tốt hết sử dụng sequence numbers Trong tương lai, mở rộng cho DTLS qui định cho phép sử dụng sequence numbers cho việc triển khai mơi trường bị hạn chế Một số phương tiện, ví dụ DCCP, cung cấp điểu khiển tắc nghẽn cho luồng thực thi chúng Nếu cửa sổ tắc nghẽn đủ hẹp, việc truyền lại handshake DTLS ngăn lại thay truyền ngay, dẫn tới timeout giả truyền lại Khi DTLS sử dụng phương tiện đó, cần có quan tâm để khơng bị tràn cửa sổ có khả tắc nghẽn Trong tương lai, DTLSDCCP mapping qui định để cung cấp hành vi tối ưu cho tương tác 2.1.1.1 Tìm hiểu PMTU Nhìn chung, nguyên tắc DTLS tránh đối phó với vấn đề PMTU Chiến lược chung bắt đầu với ước lượng MTU sau cập nhật chúng kiện handshake giai đoạn vận chuyển liệu ứng dụng thực tế yêu cầu đến PMTU nên khởi tạo từ giao diện MTU, dùng để gửi gói tin Nếu việc thực DTLS nhận thông điệp ICMP Destination Unreachable với đoạn mã “fragmentation needed and DF set”, nên giảm PMTU ước lượng thông điệp ICMP Sự thực DTLS nên cho phép ứng dụng cài đặt lại ước lượng PMTU điều khiển trạng thái DF bit Những điều khiển cho phép ứng dụng thực phát PMTU Một trường hợp đặc biệt hệ thống DTLS handshake Thông điệp handshake nên cài đặt với DF set số tường lửa định tuyến lọc thông điệp ICMP, khó để lớp handshake phân biệt gói tin ước tính PMTU chồng chéo Để cho phép kết nối trường hợp này, việc triển khai DTLS nên back off kích thước gói handshake q trình truyền lại backoff mơ tả phần 4.2.4 Ví dụ, gói tin lớn gửi sau lần truyền lại, lớp handshake chọn phân mảnh thông điệp handshake để truyền lại Nói chung, lựa chọn MTU ban đầu tránh vấn đề 2.1.2 Bảo vệ khối ghi Giống TLS, DTLS truyền liệu dạng chuỗi ghi bảo vệ Các phần lại phần mơ tả chi tiết định dạng 2.1.2.1 MAC Khung MAC DTLS giống với TLS 1.1 Tuy nhiên thay sử dụng sequence number ngầm TLS, sequence number sử dụng để tính tốn khung MAC giá trị 64 bit, tạo thành cách ghép nối epoch sequence number theo thứ tự chúng xuất dây chuyền Chú ý: DTLS epoch+sequence number có chiều dài với TLS sequence number Việc tính tốn TLS MAC tham số hóa phiên giao thức, trường hợp DTLS, chuỗi phiên Lưu ý khác biệt quan trọng xử lý DTLS TLS MAC lỗi MAC TLS phải dẫn đến ngắt kết nối Trong DTLS việc thực nhận đơn giản loại bỏ ghi lỗi tiếp tục kết nối Sự thay đổi khả thi ghi DTLS không phụ thuộc vào giống ghi TLS Nói chung thực DTLS âm thầm loại bỏ liệu với khung MAC xấu Nếu việc triển khai DTLS chọn đưa cảnh báo nhận thơng điệp có khung MAC khơng hợp lệ, phải tạo cảnh báo ghi MAC xấu với mức độ cao chấm dứt trạng thái kết nối 2.1.2.2 Luồng mật mã chuẩn NULL Mật mã NULL thực giống hệt TLS 1.1 Chỉ có luồng mật mã mô tả TLS 1.1 RC4, mà truy cập cách ngẫu nhiên RC4 không phép sử dụng DTLS 2.1.2.3 Khối mật mã 10 Khối mật mã DTLS giống hệt TLS 1.1 2.1.2.4 Bộ mật mã Khi đăng ký mật mã TLS phải cho biết liệu có hợp với DTLS khơng gì, có thích ứng phải thực 2.1.2.5 Chống truyền lại Các tin DTLS chứa sequence number để cung cấp chế truyền lại Việc xác minh sequence number nên thực sử dụng thủ tục cửa sổ trượt sau Bộ đếm gói tin cho phiên phải khởi tạo phiên thiết lập Với ghi nhận được, bên nhận phải kiểm chứng ghi chứa sequence number khơng trùng lặp với sequence number nhận suốt phiên Đây bước kiểm tra cho gói tin sau tới mục tiêu, để nhanh chóng từ chối ghi trùng Sự trùng lặp từ chối xuyên suốt cửa sổ trượt (cách thức thực cửa sổ vấn đề cục đoạn văn sau mô tả chức mà việc triển khai phải đưa ra) Cửa sổ nhỏ có kích thước 32 phải hỗ trợ cửa sổ với kích thước 64 tốt nên đặt làm mặc định Những kích thước khác chọn bên nhận Cạnh bên phải cửa sổ đại diện cho giá trị sequence number cao có hiệu lực phiên Các ghi chứa sequence number thấp cạnh bên trái cửa sổ bị từ chối Các gói tin rơi vào cửa sổ kiểm tra dựa vào danh sách gói tin nhận cửa sổ Một phương tiện hiệu để thực việc kiểm tra này, dựa sở sử dụng bit mask Nếu ghi nhận rơi cửa sổ mới, gói tin nằm bên phải cửa sổ, người nhận tiếp tục xác minh khung MAC Nếu xác minh thất bại, bên nhận phải loại bỏ ghi không hợp lệ Cửa sổ nhận cập nhật chứng thực khung MAC thành công 2.2 Giao thức Handshake DTLS DTLS sử dụng tất tin handshake luồng giống TLS, với thay đổi sau đây: - Sự trao đổi cookie khơng rõ nguồn gốc thêm vào để ngăn chặn công từ chối dịch vụ (denial of service attack) - Sửa đổi phần header handshake để xử lý thông điệp, xếp lại, phân mảnh - Bộ đếm thời gian truyền lại để xử lý thơng điệp Ngồi ngoại lệ này, định dạng thông điệp DTLS, luồng logic giống với TLS 1.1 11 2.2.1 Đối phó với denial of service Giao thức bảo mật datagram nhạy cảm với công từ chối dịch vụ Hai công đặc biệt quan ngại là: - Kẻ cơng tiêu thụ tài ngun q mức server truyền chuỗi yêu cầu handshake, khiến cho server phải phân bổ trạng thái có khả chi phí lớn cho hoạt động mã hóa - Kẻ cơng sử dụng server làm khuếch đại cách gửi thông điệp khởi tạo kết nối với nguồn giả mạo nạn nhân Server sau tiếp tục gửi thơng điệp (trong DTLS, chứng thơng điệp lớn) cho máy nạn nhân, gây tải cho máy nạn nhân Để chống lại công này, DTLS sử dụng kỹ thuật cookie không nguồn gốc (stateless cookie technique) Khi client gửi thông điệp ClientHello tới server, server có thể phản hồi với thông điệp HelloVerifyRequest Thông điệp mang cookie không nguồn gốc Các client phải truyền lại ClientHello với cookie thêm vào Server sau xác minh cookie xử lý handshake hợp lệ Cơ chế buộc kẻ công client nhận cookie, điều làm cho công Dos (denial of service) với địa IP giả mạo gặp khó khăn Cơ chế không cung cấp khả chống lại công Dos địa IP hợp lệ Quá trình trao đổi: Client -ClientHello > < - ClientHello (with cookie) Server -HelloVerifyRequest (contains cookie) > [Rest of handshake] DTLS sau điều chỉnh thơng điệp ClientHello để thêm vào giá trị cookie struct { ProtocolVersion client_version; Random random; SessionID session_id; opaque cookie; CipherSuite cipher_suites; CompressionMethod compression_methods; } ClientHello; // New field 12 Khi gửi clientHello đầu tiên, client chưa có cookie, trường hợp trường cookie để trống (độ dài =0) Định nghĩa HelloVerifyRequest là: struct { ProtocolVersion server_version; opaque cookie; } HelloVerifyRequest; Kiểu thông điệp hello_verify request (3) Server_vesion định nghĩa TLS Khi phản hổi HelloVerifyRequest, client phải sử dụng giá trị tham số (version, random, session_id, cipher_suites, compression_method) làm với ClientHello Server nên sử dụng giá trị để tạo cookie xác minh giá trị vào lúc cookie nhận Server phải sử dụng version HelloVerifyRequest gửi ServerHello Khi nhận ServerHello, client phải xác minh số phiên server phù hợp Server DTLS nên tạo cookies cách để chúng xác minh mà không cần giữ lại trạng thái client server Một kỹ thuật tạo bảo mật ngẫu nhiên tạo cookies là: Cookie = HMAC (Secret, ClientIP, Client-Parameters) Khi ClientHello thứ hai nhận, server xác minh cookie hợp lệ client nhận gói tin địa IP cho Một cơng tiềm vào chương trình kẻ công thu thập số lượng cookies từ địa khác sau tái sử dụng chúng để cơng server Server chống lại công việc thay đổi giá trị bảo mật thường xuyên, làm vơ hiệu hóa cookies Nếu server muốn clients hợp lệ sử dụng handshake qua q trình chuyển đổi (ví dụ chúng nhận cookie với Secret sau gửi ClientHello thứ hai sau server đổi thành Secret 2), server có cửa sổ giới hạn chấp nhận hai secrets DTLS server nên thực trao đổi cookie handshake thực Nếu server vận hành môi trường nơi mà khuếch đại vấn đề, server định cấu hình để khơng thực trao đổi cookie Trường hợp mặc định việc trao đổi thực Hơn server chọn khơng trao đổi cookie phiên tiếp tục Clients phải chuẩn bị để thực trao đổi cookie với handshake 13 Nếu HelloVerifyRequest sử dụng, ClientHello khởi tạo ban đầu HelloVerifyRequest không bao gồm tính tốn verify_data cho thơng điệp Finished 2.2.2 Định dạng thông điệp handshake Để hỗ trợ cho việc thông điệp, xếp lại phân mảnh, DTLS điều chỉnh phần header TLS handshake: struct { HandshakeType msg_type; uint24 length; uint16 message_seq; field uint24 fragment_offset; field uint24 fragment_length; field select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case hello_verify_request: HelloVerifyRequest; case server_hello: ServerHello; case certificate:Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done:ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished:Finished; } body; } Handshake; // New // New // New // New type Thông điệp mà bên truyền tải handshake ln có message_seq=0 Bất thơng điệp khởi tạo, giá trị message_seq tăng thêm Khi thông điệp gửi lại, giá trị message_seq giống sử dụng Ví dụ: Client -ClientHello (seq=0) Server -> X< HelloVerifyRequest (seq=0) (lost) [Timer Expires] ClientHello (seq=0) (retransmit) ClientHello (seq=1) (with cookie) > < HelloVerifyRequest (seq=0) > < -< -< ServerHello (seq=1) Certificate (seq=2) ServerHelloDone (seq=3) [Rest of handshake] 14 Lưu ý: nhiên, từ quan điểm lớp ghi DTLS, việc truyền tải lại ghi Bản ghi có giá trị DTLSPlaintext.sequence_number Việc triển khai DTLS trì đếm next_receive_seq Bộ đếm khởi tạo Khi thông điệp nhận, sequence number mà phù hợp với next_receive_seq, next_receive_seq tăng lên thông điệp tiến hành Nếu sequence number < next_receive_seq, thông điệp phải bị loại bỏ Nếu sequence number > next_receive_seq, việc triển khai nên cho thơng điệp vào hàng đợi loại bỏ 2.2.3 Phân mảnh thơng điệp tái lắp ráp Mỗi thông điệp DTLS phải phù hợp lớp truyền tải gói tin đơn giản Tuy nhiên, thơng điệp handshake có khả lớn kích thước lớn ghi Do đó, DTLS cung cấp chế phân mảnh thông điệp handshake thành nhiều ghi Khi truyền tải thông điệp handshake, người gửi chia thông điệp loạt N dãy liệu liền kề Các dãy không lớn kích thước lớn mảnh phải chứa tồn thơng điệp handshake Các dãy khơng chồng lên Người gửi sau tạo N thơng điệp handshake có giá trị message_seq với thông điệp handshake ban đầu Mỗi thông điệp đánh nhãn với fragment_offset fragment_length Tổng chiều dài tất thông điệp giống với chiều dài thông điệp ban đầu Một thông điệp không bị phân mảnh trường hợp suy thoái với fragment_offset=0 fragment_length=length Khi việc triển khai DTLS nhận mảnh thông điệp handshake, phải cho mảnh vào hàng đợi đến có tồn thơng điệp handshake Việc triển khai DTLS phải có khả điều khiển dãy mảnh chồng Điều cho phép người gửi truyền lại thơng điệp handshake với kích thước mảnh nhỏ xun suốt việc tìm kiếm MTU Lưu ý giống TLS, nhiều thơng điệp handshake bị đặt ghi DTLS giống nhau, DTLS cung cấp room chúng lần gửi Do đó, có hai cách chấp nhận để đóng gói hai thơng điệp DTLS vào gói liệu: ghi tương tự ghi khác biệt 2.2.4 Timeout truyền lại Các thông điệp DTLS nhóm lại dãy để gửi sơ đồ Mặc dù lần gửi gồm số thơng điệp Chúng nên xem khối cho mục đích thời gian chờ truyền lại Client Server 15 ClientHello > < - ClientHello HelloVerifyRequest Flight > < -Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished Flight Flight ServerHello Certificate* ServerKeyExchange* CertificateRequest* ServerHelloDone \ \ Flight / / \ \ Flight / > < / [ChangeCipherSpec] Finished \ Flight / Figure Message flights for full handshake Client -ClientHello Server -> < -[ChangeCipherSpec] Finished Flight ServerHello [ChangeCipherSpec] Finished > \ Flight / \Flight / Figure Message flights for session-resuming handshake (no cookie exchange) DTLS sử dụng chế timeout truyền lại đơn giản với tình trạng máy Bởi DTLS clients gửi thơng điệp (ClientHello), chúng bắt đầu với trạng thái PREPARING DTLS servers bắt đầu với trạng thái WAITING, với đệm trống khơng có đếm thời gian truyền lại 16 + -+ | PREPARING | + -> | | < + | | | | | + -+ | | | | | | | | | Buffer next flight | | | | | \|/ | | + -+ | | | | | | | SENDING |< + | | | | | | | + -+ | | Receive | | | | next | | Send flight | | flight | + + | | | | | Set retransmit timer | | | | \|/ | | | | + -+ | | | | | | | | + ) | WAITING | -+ | | | | | Timer expires | | | | + -+ | | | | | | | | | | | | | | + + | | | Read retransmit | Receive | | | last | | | flight | | | | | | \|/\|/ | | + -+ | | | | | FINISHED | -+ | | + -+ Send HelloRequest or Receive HelloRequest Send ClientHello Figure DTLS timeout and retransmission state machine Trạng thái máy có trạng thái Trong trạng thái PREPARING, việc triển khai tính tốn cẩn thiết để chuẩn bị cho thông điệp lần gửi Sau chúng đưa vào đệm để vào trạng thái SENDING Trong trạng thái SENDING, thực truyền thông điệp lấy từ đệm Khi thông điệp gửi, việc triển khai sau vào trạng thái FINISHED lần gửi cuối handshake Hoặc, việc triển khai mong đợi nhận nhiều thông điệp hơn, đặt đếm thời gian truyền lại sau vào trạng thái WAITING Có cách để thoát khỏi trạng thái WAITING: 17 Bộ đếm thời gian truyền lại kết thúc: việc thực đến trạng thái SENDING, nơi mà thực truyền lại, thiết lập đếm thời gian truyền lại, quay lại trạng thái WAITING Việc thực đọc lần truyền lại từ tương đương: việc chuyển đổi sang trạng thái SENDING, nơi mà gửi lại, đặt lại đếm thời gian truyền lại, trở trạng thái WAITING Cơ sở nhận tin nhắn trùng lặp giống kết việc hết thời gian tương đương cho thấy phần lần gửi trước bị Việc thực nhận thông điệp gửi: Nếu lần gửi cuối thơng điệp, việc thực chuyển đến FINISHED Nếu việc thực cần lần gửi mới, chuyển đến trạng thái PREPARING Việc đọc phần (một mẩu thông điệp hay thơng điệp lần gửi) khơng gây trình chuyển đổi trạng thái hay đặt lại hẹn Bởi DTLS clients gửi thơng điệp (ClientHello), chúng bắt đầu vào trạng thái PREPARING DTLS servers bắt đầu vào trạng thái WAITING, với đệm trống khơng có đếm thời gian truyền lại Khi server mong muốn rehandshake, chuyển từ FINISHED sang PREPARING để gửi HelloRequest Khi client nhận HelloRequest, chuyển từ FINISHED sang PREPARING để gửi ClientHello 2.2.4.1 Giá trị hẹn Mặc dù giá trị hẹn lựa chọn việc thực hiện, xử lý sai thời gian dẫn đến vấn đề tắc nghẽn nghiêm trọng, ví dụ lời yêu cầu DTLS hết sớm việc truyền lại nhanh đường dẫn chật hẹp Việc thực nên sử dụng giá trị đếm thời gian ban đầu giây giá trị lần truyền lại Lưu ý nên sử dụng hẹn giây thay giây mặc định để cải thiện độ trễ cho ứng dụng nhạy cảm với thời gian Bởi DTLS sử dụng truyền lại cho handshake không cho dataflow, ảnh hưởng dẫn đến tắc nghẽn tối thiểu Việc triển khai nên giữ lại giá trị đếm thời gian việc truyền tải không xảy mát, thời điểm giá trị đặt lại giá trị ban đầu Sau thời gian dài nghỉ ngơi, khơng 10 lần giá trị đếm thời gian tại, việc triển khai đặt lại đếm thời gian giá trị ban đầu Một tình mà điều vừa nói xảy rehandshake sử dụng sau truyền liệu đáng kể 2.2.5 ChangeCipherSpec Giống với TLS, thông điệp ChangeCipherSpec thông điệp handshake mặt kỹ thuật phải coi phần lần 18 gửi tương tự kết giao thơng điệp Finished cho mục đích timeout truyền lại 2.2.6 Finished Messages Finished messages có định dạng giống TLS Tuy nhiên, để loại bỏ độ nhạy cảm việc phân mảnh, Finished MAC phải tính tốn thơng điệp handshake gửi phải mảnh Lưu ý nhiều trường hợp việc trao đổi cookie sử dụng, ClientHello HelloVerifyRequest ban đầu không bao gồm Finished MAC 2.2.7 Alert Messages Lưu ý Alert Messages không truyền lại tất trường hợp, chúng xuất bối cảnh handshake Tuy nhiên, việc thực DTLS nên tạo thông điệp cảnh báo ghi lỗi nhận lần 2.3 Tóm tắt cú pháp Phần bao gồm số thay đổi cấu trúc liệu TLS 1.1 DTLS 2.3.1 Record Layer struct { ContentType type; ProtocolVersion version; uint16 epoch; // New field uint48 sequence_number; // New field uint16 length; opaque fragment[DTLSPlaintext.length]; } DTLSPlaintext; struct { ContentType type; ProtocolVersion version; uint16 epoch; // New field uint48 sequence_number; // New field uint16 length; opaque fragment[DTLSCompressed.length]; } DTLSCompressed; struct { ContentType type; ProtocolVersion version; uint16 epoch; uint48 sequence_number; uint16 length; select (CipherSpec.cipher_type) { case block: GenericBlockCipher; } fragment; } DTLSCiphertext; // New field // New field 2.3.2 Handshake Protocol enum { 19 hello_request(0), client_hello(1), server_hello(2), hello_verify_request(3), // New field certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) } HandshakeType; struct { HandshakeType msg_type; uint24 length; uint16 message_seq; uint24 fragment_offset; uint24 fragment_length; // New field // New field // New field select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case hello_verify_request: HelloVerifyRequest; // New field case certificate:Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done:ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished:Finished; } body; } Handshake; struct { ProtocolVersion client_version; Random random; SessionID session_id; opaque cookie; // New field CipherSuite cipher_suites; CompressionMethod compression_methods; } ClientHello; struct { ProtocolVersion server_version; opaque cookie; } HelloVerifyRequest; CHÚ Ý BẢO MẬT Tài liệu mô tả biến thể TLS 1.1 hầu hết ý bảo mật giống TLS 1.1 Chú ý bảo mật bổ sung DTLS đưa việc từ chối dịch vụ DTLS bao gồm trao đổi cookie thiết kế để bảo vệ đề phòng việc từ chối dịch vụ Tuy nhiên, việc triển khai khơng sử dụng việc trao đổi cookie dễ bị công DoS Cụ thể là, dịch vụ mà khơng sử dụng việc trao đổi cookie sử dụng khuếch đại công chí thân chúng chưa trải nghiệm DoS Vì vậy, máy chủ DTLS nên sử dụng trao đổi cookie trừ có lí thuyết phục khuếch đại không đe dọa đến môi trường 20 chúng Các client phải chuẩn bị trao đổi cookie với handshake MÔ PHỎNG HOẠT ĐỘNG CỦA DTLS ĐỂ KIỂM TRA HANDSHAKE: -Cố gắng thiết lập mạng mô Contiki cooja để kiểm tra DTLS Handshake DTLS-client Server -Sử dụng “swismote” làm tảng đích phát hành Contiki tinyDTLS -Theo ví dụ mặc định cung cấp tinyDTSL không thực Handshake Ta phải thực Handshake tay từ tinyDTLS-client cách gọi: “try_send (dtls_context, & dst);" sau PROCESS_WAIT_EVENT_UNTIL (etimer_expired (& et1)); -sau thực mô Handshake Contiki cooja thu Handshake theo kết sau: 21 22 23 KẾT LUẬN Việc áp dụng DTLS giao thức UDP cách sử dụng cải tiến linh hoạt giao thứ TLS cách hiệu để đáp ứng chạy UDP Nó ứng dụng nhiều lĩnh vực live stream, game online, … sử dụng giao thức UDP Trên báo cáo tổng hợp nhóm em tìm hiểu giao thức DTLS mô khách quan cách hoạt động giao thức Bài báo cáo nhiều thiếu sót chúng em mong nhận góp ý từ để cải thiện Nhóm chúng em xin chân thành cảm ơn 24 TÀI LIỆU THAM KHẢO Trang web https://tools.ietf.org/ Web https://vi.wikipedia.org Một số trang web khác 25