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ỘIVIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

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 2

LỜI MỞ ĐẦU 3

PHẦN I: GIỚI THIỆU CHUNG 4

1 Hoàn cảnh ra đời 4

2 Cấu trúc giao thức DTLS 5

3 Mô hình sử dụng 5

PHẦN II: HOẠT ĐỘNG CỦA GIAO THỨC 6

1 Tổng quan 6

1.1 Truyền thông vô cảm 6

1.2 Cung cấp độ tin cậy cho Handshake 6

1.2.1 Mất gói tin 6

1.2.2 Sắp xếp lại 7

1.2.3 Kích thước thông điệp 7

1.3 Phát hiện sự phát lại 7

2 Sự khác biệt với TLS 8

2.1 Lớp bản ghi 8

2.1.1 Transport Layer Mapping 9

2.1.1.1 Tìm hiểu về PMTU 9

2.1.2 Bảo vệ khối bản ghi 10

2.1.2.1 MAC 10

2.1.2.2 Luồng mật mã chuẩn hoặc NULL 10

2.1.2.3 Khối mật mã 11

2.1.2.4 Bộ mật mã mới 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 và tái lắp ráp 15

2.2.4 Timeout và truyền lại 15

2.2.4.1 Giá trị bộ hẹn giờ 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ác cú pháp mới 19

2.3.1 Record Layer 19

2.3.2 Handshake Protocol 20

3 chú ý bảo mật 20

4 Mô phỏng hoạt động của 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ủa công nghệ hiện nay ngày càng đặt ra những yêu cầu mang tính cấp thiết cũng như để đáp ứng những nhu cầu cập nhật từng ngày từng giờ, chúng ta cần phải đưa ra những giải pháp phù hợp và hiệu quả Toàn cầu hóa và công cuộc xây dựng ngành công nghiệp 4.0 là cơ sở cho sự ra đời những phát minh mới Trong lĩnh vực truyền thông và mạng máy tính, số lượng giao thức sử dụng trong mạng máy tính được ra đời tăng một cách nhanh chóng Trên cơ sở những giao thức cũ, hai giao thức TCP và UDP tỏ ra hiệu quả hơn hếtcho những mục đích cụ thể trong tầng vận chuyển Tuy nhiên, vì những khác biệt cơ bản giữa hai giao thức mà phương thức bảo mật cho TCP thiếu hiệu quả trên UDP Vấn đề đặt ra là cần cải tiến một cách linh hoạt tạo ra một giao thức bảo mật mới đáp ứng được trên giao thức UDP trên cơ sở một giao thức bảo mậtcủa TCP Điều này sẽ tận dụng được ưu điểm của cả hai giao thức cũng như tănghiệu quả sử dụng Trong bài báo cáo này nhóm em sẽ trình bày về giao thức Datagram Transport Layer Security (DTLS), được phát triển dựa trên giao thức Transport Layer Security (TLS) và được sử dụng trên UDP

PHẦN I: GIỚI THIỆU CHUNG

1 HOÀN CẢNH RA ĐỜI.

TLS là 1 giao thức đã được triển khai rộng rãi cho việc bảo mật truyền tải mạng Nó được sử dụng cho việc bảo vệ truyền tải web và cho các giao thức email imap và pop Lợi ích chính của TLS là nó cung cấp 1 kênh kết nối minh bạch-kênh định hướng Vì vậy chúng ta rất dễ để bảo vệ 1 giao thức ứng dụng bằng cách chèn TLS giữa lớp ứng dụng và lớp truyền tải trong mô hình OSI Tuy nhiên, TLS phải chạy thông qua 1 kênh vận chuyển đáng tin cậy (thường là TCP) Cho nên nó không thể được sử dụng để bảo đảm việc truyền tải những góitin không đáng tin cậy

Trong vài năm trở lại đây, ngày càng có nhiều giao thức lớp ứng dụng đã được thiết kế cho việc truyền tải UDP Một giao thức cụ thể như Session

Initiation Protocol (SIP) và các giao thức game điện tử đang ngày càng phổ biến (lưu ý rằng SIP có thể chạy trên cả TCP và UDP nhưng có nhiều tình huống dùng UDP sẽ thích hợp hơn) Gần đây, những nhà thiết kế ứng dụng phải đối mặt với nhiều lựa chọn không đạt yêu cầu Đầu tiên, họ có thể sử dụng giao thứcIPsec Tuy nhiên, đối với 1 số lý do, IPsec chỉ thích hợp cho 1 số ứng dụng Thứ hai, họ có thể thiết kế 1 giao thức bảo mật lớp ứng dụng SIP sử dụng 1 phần củaS-MIME để đảm bảo việc truyền tải của nó Thật không may, mặc dù giao thức bảo mật lớp ứng dụng thường cung cấp các đặc tính bảo mật cao cấp, ví dụ bảo mật end-to-end trong trường hợp của S-MIME, nhưng chúng thường đòi hỏi nhiều công sức để thiết kế và lại ít được sử dụng để chạy giao thức trên TLS

Trong nhiều trường hợp, cách tốt nhất để bảo vệ các ứng dụng

client/server là nên sử dụng TLS Tuy nhiên, do yêu cầu về ngữ nghĩa gói tin tự động cấm việc sử dụng giao thức TLS Do đó một biến thể tương thích của TLS,

sẽ rất được kỳ vọng Tài liệu này sẽ mô tả chi tiết về giao thức DTLS -

Datagram Transport Layer Security DTLS được thiết kế rất giống với TLS, giảm thiểu những phát minh bảo mật và tăng việc tái sử dụng code và cơ sở vật chất

2 CẤU TRÚC GIAO THỨC DTLS.

3 MÔ HÌNH SỬ DỤNG.

Giao thức DTLS được thiết kế để bảo vệ dữ liệu trong giao tiếp giữa các ứng dụng Nó được thiết kế để chạy trong không gian ứng dụng, với việc không

có bất kỳ yêu cầu sửa đổi bên trong nào

Việc truyền tải gói tin không yêu cầu cung cấp đáng tin cậy hoặc theo thứ

tự phân phối dữ liệu Giao thức DTLS duy trì thuộc tính này cho dữ liệu tải trọng Các ứng dụng như truyền phát trực tuyến, gọi điện qua internet và game online sử dụng truyền tải gói tin để giao tiếp do sự chậm trễ - tính chất nhạy cảmcủa dữ liệu vận chuyển Hành vi của các ứng dụng như vậy không thay đổi khi giao thức DTLS được sử dụng để an toàn giao tiếp bởi vì giao thức DTLS không

bù đắp cho lượng dữ liệu bị mất hoặc được sắp xếp lại

Nguyên lý thiết kế cơ bản của DTLS là xây dựng “TLS trên gói tin” Lý

do TLS không thể được sử dụng trực tiếp trong môi trường gói tin, đơn giản là

vì các gói có thể bị mất hoặc được sắp xếp lại Bản chất của TLS là không thể tự

xử lý trường hợp không đáng tin cậy này, vì thế việc triển khai TLS bị hỏng khi được lưu trữ lại trên truyền tải gói tin Mục đích của DTLS là chỉ tạo ra thay đổi tối thiểu để có thể yêu cầu TLS khắc phục sự cố này Đến một mức tối đa, DTLS

sẽ giống với TLS Bất cứ khi nào chúng ta cần tạo ra một cơ chế mới, chúng ta

cố gắng làm theo cách bảo tồn lại cấu trúc của TLS

PHẦN II: HOẠT ĐỘNG CỦA GIAO THỨC

1 TỔNG QUAN.

Sự không đáng tin cậy tạo ra các vấn đề cho TLS ở hai mức:

- Lớp mã hóa truyền tải của TLS không cho phép việc giải mã độc lập của các bản ghi riêng rẽ Nếu bản ghi N không được nhận thì bản ghi N+1 không thể được giải mã

- Lớp TLS handshake giả định rằng các thông điệp handshake sẽ được vận chuyển một cách đáng tin cậy và sẽ bị hỏng nếu các thôngđiệp handshake bị mất

Phần tiếp theo sẽ mô tả cách DTLS giải quyết các vấn đề trên

1.1 Truyền thông vô cảm.

Ở trong lớp mã hóa truyền tải của TLS (được gọi là Record Layer của TLS), các bản ghi là không độc lập với nhau Có hai loại phụ thuộc giữa các bảnghi:

- Ngữ cảnh mật mã (trạng thái CBC, luồng khóa mật mã dòng) được nối với nhau giữa các bản ghi

- Chống phát lại và bảo vệ thứ tự thông điệp được cung cấp bởi khung MAC có chứa Sequence Numbers nhưng Sequence Numbersnày ẩn trong các bản ghi

Cách giải quyết cho cả hai vấn đề này là rất đơn giản và phổ biến trong IPsec ESP: thêm một trạng thái rõ ràng vào trong bản ghi TLS 1.1 đã thêm trạng thái CBC rõ ràng vào các bản ghi DTLS kế thừa cơ chế đó và thêm thành phần Sequence Numbers vào trong bản ghi

1.2 Cung cấp độ tin cậy cho Handshake.

Cơ chế của TLS là một cơ chế sử dụng mật mã khóa Thông điệp phải được chuyển đi và nhận lại trong một trình tự nhất định, và mọi trình tự khác đều gây ra lỗi Rõ ràng, điều này không tương thích với việc yêu cầu phát lại và

bị mất thông điệp Hơn nữa thông điệp handshake của TLS có kích thước lớn hơn bất kỳ gói dữ liệu nào đã được gửi, do đó gây ra những vấn đề phân mảnh DTLS phải cung cấp các giải pháp cho mọi vấn đề trên

1.2.1 Mất gói tin

DTLS sử dụng một bộ hẹn giờ truyền lại để xử lý việc mất gói tin Sơ đồ dưới đây minh họa các khái niệm cơ bản, sử dụng trong giai đoạn đầu tiên của DTLS handshake:

Sau khi client đã gửi thông điệp Clienthello, nó sẽ đợi HelloVerifyRequest

từ Server, tuy nhiên thông điệp bị mất thì thì Client biết rằng một trong hai thông điệp ClientHello hoặc HelloVerifyRequest đã bị mất và sẽ truyền lại Khi server nhận được thông điệp truyền lại thì nó sẽ truyền lại Server cũng duy trì một bộ hẹn giờ truyền lại, và sẽ thực hiện truyền lại khi bộ đếm chạy hết giờ

Lưu ý: Timeout và cơ chế truyền lại không được áp dụng cho bản tin HelloVerifyRequest bởi vì nó yêu cầu tại một trạng thái trên server

1.2.2 Sắp xếp lại

Trong DTLS mỗi thông điệp handshake được phát cho một Sequence number riêng Khi một bên nhận được thông điệp handshake, nó sẽ nhanh chóngxác định đó có phải là thông điệp nó mong đợi hay không Nếu đúng, nó xử lý thông điệp đó Ngược lại, thông điệp được đưa vào hàng đợi để xử lý sau khi nhận được tất cả các thông điệp trước nó

1.2.3 Kích thước thông điệp

Thông điệp handshake của TLS và DTLS có thể khá lớn, trong lý thuyết

có thể lên tới 2^24-1 bytes, trong thực tế là hàng kilobytes Ngược lại những gói

dữ liệu UDP thường nhỏ hơn 1500 bytes Nếu sự phân mảnh không như mong đợi Để bù đắp cho sự hạn chế này, mỗi thông điệp handshake DTLS có thể cần được phân mảnh thành một số bản ghi DTLS Mỗi thông điệp DTLS handshake bao gồm offset cảu mảnh và độ dài mảnh Do đó, bên nhận sở hữu tất cả các bytes của một thông điệp handshake sẽ có thế ghép lại thành thông điệp ban đầu khi chưa bị phân mảnh

1.3 Phát hiện sự phát lại.

DTLS hỗ trợ phát hiện sự phát lại bản ghi Kỹ thuật được sử dụng ở đây giống với trong IPsec AH/ESP, bằng cách duy trì một cửa sổ bitmap của các bản ghi đã nhận Các bản ghi quá cũ để phù hợp với cửa sổ và những bản ghi được nhận trước đây sẽ bị loại bỏ Đặc tính của phát hiện phát lại là tùy chọn, vì sự trùng lặp gói tin là không lúc nào cũng gây nguy hiểm nhưng cũng có thể dẫn đến lỗi định tuyến Các ứng dụng có thể phát hiện các gói tin trùng lặp và điều chỉnh chiến lược truyền tải dữ liệu cho phù hợp

2 SỰ KHÁC BIỆT VỚI TLS.

Như đã đề cập ở phần 1, DTLS rất giống với TLS Vì thế thay cho việc giới thiệu DTLS như một giao thức mới thì chúng ta sẽ giới thiệu nó như một phiên bản của TLS 1.1 Ở những chỗ chúng ta không chỉ ra sự khác biệt một cách rõ ràng, DTLS giống hệt TLS 1.1

2.1 Lớp bản ghi.

Lớp bản ghi của DTLS cực kỳ giống với TLS 1.1 Sự thay đổi duy nhất là

nó có bao gồm Sequence number trong bản ghi Sequence number cho phép bên nhận xác thực chính xác khung MAC TLS Khuôn dạng bản ghi DTLS được mô

tả như 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 trong bản ghi TLS 1.1

-version: phiên bản giao thức đang được sử dụng-epoch: một giá trị biến đếm tăng lên mỗi khi trạng thái mật mã được thay đổi

- sequence number: sequence number của bản ghi này -length: bằng độ dài của bản ghi trong TLS 1.1, không nên vượt quá2^14 bytes

- fragment: giống với bản ghi của TLS 1.1DTLS sử dụng sequence number tường minh thay vì ngầm định Được gắn trong trường sequence number của bản ghi Với TLS, sequence number được đặt bằng 0 sau mỗi thông điệp ChangeCipherSpec được gửi

Nếu một vài handshake được thực hiện một cách kế tiếp nhau, sẽ có thể

có nhiều bản ghi bị trùng sequence number nhưng khác nhau về trạng thái mật

mã Trường epoch cho phép bên nhận phân biệt các gói như vậy Số epoch ban đầu là 0 và sẽ được tăng sau mỗi lần thông điệp ChangeCipherSpec được gửi đi

Để đảm bảo rằng mỗi cặp sequence-epoch là duy nhất, quá trình thực hiện

không cho phép giá trị epoch giống nhau được sử dụng hai lần trong thời gian tồn tại của một phân đoạn Thực tế, quá trình thực hiện TLS hiếm khi thực hiện lại handshake cho nên đây không phải là một vấn đề đáng quan tâm

2.1.1 Transport Layer Mapping

Mỗi bản ghi DTLS phải phù hợp với một gói dữ liệu duy nhất Để tránh

sự phân mảnh IP, sự triển khai DTLS nên xác định rõ MTU và gửi các bản ghi nhỏ hơn MTU Sự triển khai DTLS nên cung cấp một cách cho các ứng dụng để xác định giá trị của PMTU (hoặc là luân phiên, hoặc kích cỡ tối đa của gói dữ liệu ứng dụng là PMTU trừ đi chi phí mỗi bản ghi DTLS) Nếu ứng dụng cố gửi một bản ghi lớn hơn MTU, việc triển khai DTLS sẽ gặp lỗi, do đó tránh gửi một gói sẽ bị phân mảnh

Lưu ý rằng không giống như IPsec, các bản ghi DTLS không bao gồm bất

kì số liên kết nhận dạng nào Các ứng dụng phải sắp xếp để ghép nối giữa các liên kết Với UDP, nó sẽ được thực hiện với số host/port

Nhiều bản ghi DTLS có thể được đặt trong một gói tin duy nhất Chúng được mã hóa đơn giản một cách liên tục Khung bản ghi DTLS vừa đủ để xác định ranh giới giữa chúng Lưu ý rằng, bytes đầu tiên của trọng tải gói tin phải làphần đầu của bản ghi Các bản ghi không thể mở rộng gói dữ liệu

Một số phương tiện, như là DCCP cung cấp những sequence number của riêng chúng Khi thực hiện qua các phương tiện đó, cả DTLS và những sequencenumber của các phương tiện đó sẽ được chỉ định Mặc dù điều này phát sinh một

số lượng nhỏ những thứ không hiệu quả, lớp vận chuyển và những sequence number của DTLS phục vụ những mục đích khác nhau, và do đó để đơn giản khái niệm, tốt hơn hết là sử dụng 2 sequence numbers Trong tương lai, sự mở rộng cho DTLS có thể được qui định cho phép sử dụng chỉ 1 bộ sequence

numbers cho việc triển khai trong 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 được thực thi trên chúng Nếu cửa sổ tắc nghẽn đủ hẹp, việc truyền lại handshake DTLS sẽ được ngăn lại thay vì truyền ngay, có thể dẫn tới timeout và giả truyền lại Khi DTLS được sử dụng trên các phương tiện đó, cần có sự quan tâm để không bị tràn cửa sổ có khả năng tắc nghẽn Trong tương lai, DTLS-DCCP mapping sẽ được qui định để cung cấp những hành vi tối ưu cho sự tươngtác này

2.1.1.1 Tìm hiểu về PMTU

Nhìn chung, nguyên tắc của DTLS là tránh đối phó với các vấn đề PMTU.Chiến lược chung là bắt đầu với một sự ước lượng MTU và sau đó cập nhật chúng nếu sự kiện nào trong handshake hoặc giai đoạn vận chuyển dữ liệu ứng dụng thực tế yêu cầu đến nó

PMTU nên được khởi tạo từ giao diện MTU, cái được dùng để gửi gói tin.Nếu việc thực hiện DTLS nhận một thông điệp ICMP Destination Unreachable với đoạn mã “fragmentation needed and DF set”, nó nên giảm PMTU được ước lượng trong thông điệp ICMP Sự thực hiện DTLS nên cho phép ứng dụng cài

đặt lại ước lượng PMTU của nó và điều khiển trạng thái của DF bit Những điềukhiển này cho phép ứng dụng thực hiện phát hiện PMTU.

Một trường hợp đặc biệt là hệ thống DTLS handshake Thông điệp

handshake nên được cài đặt với DF set bởi vì một số tường lửa và bộ định tuyến lọc ra thông điệp ICMP, rất khó để lớp handshake phân biệt gói tin mất do ước tính PMTU chồng chéo Để cho phép kết nối trong những trường hợp này, việc triển khai DTLS nên back off kích thước gói handshake trong quá trình truyền lại backoff được mô tả trong phần 4.2.4 Ví dụ, nếu một gói tin lớn đang được gửi đi sau 3 lần truyền lại, lớp handshake có thể chọn phân mảnh thông điệp handshake để truyền lại Nói chung, lựa chọn của một MTU ban đầu sẽ tránh được vấn đề này

2.1.2 Bảo vệ khối bản ghi

Giống TLS, DTLS truyền dữ liệu dưới dạng một chuỗi các bản ghi đã được bảo vệ Các phần còn lại của phần này mô tả chi tiết các định dạng đó.2.1.2.1 MAC

Khung MAC DTLS giống với TLS 1.1 Tuy nhiên thay vì sử dụng

sequence number ngầm của TLS, thì sequence number được sử dụng để tính toán khung MAC là giá trị 64 bit, được tạo thành bằng cách ghép nối epoch và sequence number theo thứ tự chúng xuất hiện trong dây chuyền Chú ý: DTLS epoch+sequence number có cùng chiều dài với TLS sequence number

Việc tính toán TLS MAC được tham số hóa trong các phiên bản của giao thức, trong trường hợp DTLS, đó là một chuỗi phiên bản

Lưu ý rằng một sự khác biệt quan trọng giữa xử lý DTLS và TLS MAC làtrong các lỗi MAC của TLS phải dẫn đến ngắt kết nối Trong DTLS việc thực hiện nhận có thể chỉ đơn giản là loại bỏ những bản ghi lỗi và tiếp tục kết nối Sự thay đổi này là khả thi bởi vì các bản ghi của DTLS không phụ thuộc vào nhau giống như các bản ghi của TLS

Nói chung thực hiện DTLS âm thầm loại bỏ dữ liệu với các khung MAC xấu Nếu việc triển khai DTLS chọn đưa ra cảnh báo thì nó nhận một thông điệp

có khung MAC không hợp lệ, nó phải tạo ra cảnh báo bản ghi MAC xấu với mức độ cao nhất và chấm dứt trạng thái kết nối

2.1.2.2 Luồng mật mã chuẩn hoặc NULL

Mật mã NULL được thực hiện giống hệt TLS 1.1

Chỉ có luồng mật mã duy nhất được mô tả trong TLS 1.1 là RC4, cái mà không thể được truy cập một cách ngẫu nhiên RC4 không được phép sử dụng trong DTLS

2.1.2.3 Khối mật mã

Bộ đếm gói tin cho phiên này phải được khởi tạo về 0 khi phiên được thiết lập Với mỗi bản ghi nhận được, bên nhận phải kiểm chứng bản ghi đó chứa sequence number không trùng lặp với bất kỳ sequence number đã nhận trong suốt phiên Đây là bước kiểm tra đầu tiên cho một gói tin sau khi nó tới mục tiêu, để nhanh chóng từ chối các bản ghi trùng nhau.

Sự trùng lặp được từ chối xuyên suốt cửa sổ trượt (cách thức thực hiện cửa sổ là một vấn đề cục bộ nhưng đoạn văn bản sau mô tả chức năng mà việc triển khai phải đưa ra) Cửa sổ nhỏ nhất có kích thước 32 phải được hỗ trợ

nhưng một cửa sổ với kích thước 64 thì tốt hơn và nên được đặt làm mặc định Những kích thước khác có thể được chọn bởi bên nhận

Cạnh bên phải cửa sổ đại diện cho giá trị sequence number cao nhất có hiệu lực trong phiên này Các bản ghi chứa sequence number thấp hơn cạnh bên trái cửa sổ bị từ chối Các gói tin rơi vào trong cửa sổ được kiểm tra dựa vào danh sách các gói tin được nhận trong cửa sổ Một phương tiện hiệu quả để thực hiện việc kiểm tra này, dựa trên cơ sở sử dụng bit mask

Nếu bản ghi được nhận rơi trong cửa sổ và là mới, hoặc nếu gói tin nằm bên phải cửa sổ, thì 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ỏ bản ghi không hợp lệ Cửa sổ nhận được cập nhậtchỉ khi chứng thực khung MAC thành công

2.2 Giao thức Handshake DTLS.

DTLS sử dụng tất cả các bản tin handshake và luồng giống như TLS, với

3 thay đổi chính sau đây:

- Sự trao đổi cookie không rõ nguồn gốc được thêm vào để ngăn chặn những sự tấn công từ chối dịch vụ (denial of service attack)

- Sửa đổi phần header của handshake để xử lý mất thông điệp, sắp xếp lại, và phân mảnh

- Bộ đếm thời gian truyền lại để xử lý mất thông điệp

Ngoài những ngoại lệ này, các định dạng thông điệp của DTLS, luồng và logic đều giống với TLS 1.1

2.2.1 Đối phó với denial of service.

Giao thức bảo mật datagram cực kỳ nhạy cảm với những sự tấn công từ chối dịch vụ Hai cuộc tấn công đặc biệt quan ngại là:

- Kẻ tấn công có thể tiêu thụ tài nguyên quá mức trên server bởi truyền một chuỗi các yêu cầu handshake, khiến cho server phải phân bổ trạng thái và có khả năng mất chi phí lớn cho các hoạt động mã hóa

- Kẻ tấn công có thể sử dụng server làm bộ khuếch đại bằng cách gửithông điệp khởi tạo kết nối với một nguồn giả mạo của nạn nhân Server sau đó tiếp tục gửi thông điệp (trong DTLS, một chứng chỉ thông điệp có thể khá lớn) cho máy nạn nhân, do đó gây quá tải chomáy nạn nhân

Để chống lại các cuộc tấn công này, DTLS sử dụng kỹ thuật cookie khôngnguồn gốc (stateless cookie technique) Khi client gửi thông điệp ClientHello của nó tới server, server có thể có thể phản hồi với một thông điệp

HelloVerifyRequest Thông điệp này mang cookie không nguồn gốc Các client phải truyền lại ClientHello với cookie được thêm vào Server sau đó xác minh cookie và chỉ xử lý handshake nếu nó hợp lệ Cơ chế này buộc kẻ tấn công hoặc client nhận cookie, điều làm cho cuộc tấn công Dos (denial of service) với địa chỉ IP giả mạo sẽ gặp khó khăn hơn Cơ chế này không cung cấp khả năng chống lại các cuộc tấn công Dos bằng địa chỉ IP hợp lệ

Quá trình trao đổi:

Client Server - -