Tìm hiểu giao thức DTLS
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (3.55 MB, 25 trang )
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 0 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
1
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
2
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ết
cho 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ật
củ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ăng
hiệ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.
3
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ói
tin 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ức
IPsec. 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ủa
S-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.
4
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ảm
củ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.
5
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ản
ghi:
- 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 Numbers
nà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:
6
Client
-----ClientHello
------>
Server
------
X<-- HelloVerifyRequest
(lost)
[Timer Expires]
ClientHello
(retransmit)
------>
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óng
xá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.
7
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.1
DTLS 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.
8
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 sequence
number 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, DTLSDCCP mapping sẽ được qui định để cung cấp những hành vi tối ưu cho sự tương
tá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
9
đặ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ều
khiể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ã
10
Khối mật mã DTLS giống hệt TLS 1.1.
2.1.2.4. Bộ mật mã mới
Khi đăng ký bộ mật mã mới của TLS phải cho biết liệu nó có hợp với
DTLS không và là gì, nếu có thì sự thích ứng phải được thực hiện.
2.1.2.5. Chống truyền lại
Các bản tin DTLS chứa sequence number để cung cấp cơ chế truyền lại.
Việc xác minh sequence number nên được thực hiện bởi sử dụng thủ tục cửa sổ
trượt sau đây.
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ật
chỉ 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.
11
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ửi
thô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 cho
má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ông
nguồ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
-----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<0..32>;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
// New field
12
Khi gửi clientHello đầu tiên, client vẫn chưa có cookie, trong trường hợp
này trường cookie được để trống (độ dài =0).
Định nghĩa của HelloVerifyRequest là:
struct {
ProtocolVersion server_version;
opaque cookie<0..32>;
} HelloVerifyRequest;
Kiểu thông điệp là hello_verify request (3)
Server_vesion được định nghĩa như trong TLS
Khi phản hổi HelloVerifyRequest, client phải sử dụng cùng giá trị tham số
(version, random, session_id, cipher_suites, compression_method) như là nó đã
làm với ClientHello. Server nên sử dụng những giá trị đó để tạo ra cookie của nó
và xác minh các giá trị đó là đúng vào lúc cookie nhận được. Server phải sử
dụng cùng version trong HelloVerifyRequest khi gửi ServerHello. Khi nhận
được ServerHello, client phải xác minh số phiên bản server là phù hợp.
Server DTLS nên tạo ra các cookies như một cách để chúng xác minh mà
không cần giữ lại bất kỳ một trạng thái client nào trên server. Một kỹ thuật tạo ra
một bảo mật ngẫu nhiên và tạo ra các cookies là:
Cookie = HMAC (Secret, ClientIP, Client-Parameters)
Khi ClientHello thứ hai được nhận, server có thể xác minh rằng cookie là
hợp lệ và client có thể nhận được các gói tin tại địa chỉ IP đã cho.
Một cuộc tấn công tiềm năng vào chương trình này là kẻ tấn công sẽ thu
thập một số lượng cookies từ các địa chỉ khác nhau và sau đó tái sử dụng chúng
để tấn công server. Server có thể chống lại cuộc tấn công này bằng việc thay đổi
giá trị bảo mật thường xuyên, do đó làm vô hiệu hóa các cookies đó. Nếu server
muốn rằng các clients hợp lệ có thể sử dụng handshake qua các quá trình chuyển
đổi (ví dụ như chúng sẽ nhận một cookie với Secret 1 và sau đó gửi ClientHello
thứ hai sau khi server đổi thành Secret 2), server có thể có một cửa sổ giới hạn
trong khi nó chấp nhận cả hai secrets.
DTLS server nên thực hiện một trao đổi cookie bất cứ khi nào một
handshake mới được thực hiện. Nếu server được vận hành trong một môi trường
nơi mà bộ khuếch đại là một vấn đề, server có thể được định cấu hình để không
thực hiện một trao đổi cookie. Trường hợp mặc định là việc trao đổi đã được
thực hiện. Hơn nữa server có thể chọn không trao đổi cookie khi một phiên được
tiếp tục. Clients phải được chuẩn bị để thực hiện trao đổi cookie với mỗi
handshake.
13
Nếu HelloVerifyRequest được sử dụng, ClientHello khởi tạo ban đầu và
HelloVerifyRequest không được bao gồm trong sự tính toán của verify_data cho
thông điệp Finished.
2.2.2. Định dạng thông điệp handshake.
Để hỗ trợ cho việc mất thông điệp, sắp xếp lại và sự phân mảnh, DTLS
điều chỉnh phần header của 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 đầu tiên mà mỗi bên truyền tải trong mỗi handshake luôn có
message_seq=0. Bất cứ khi nào mỗi thông điệp mới được khởi tạo, giá trị
message_seq được tăng thêm 1. Khi một thông điệp được gửi lại, giá trị
message_seq giống trên được 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 ý: tuy nhiên, từ quan điểm của lớp bản ghi DTLS, việc truyền tải lại
là một bản ghi mới. Bản ghi này sẽ có một giá trị
DTLSPlaintext.sequence_number mới.
Việc triển khai DTLS duy trì một bộ đếm next_receive_seq. Bộ đếm này
được khởi tạo bằng 0. Khi một thông điệp được nhận, nếu sequence number mà
phù hợp với next_receive_seq, next_receive_seq được tăng lên và thông điệp
được 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 nhưng cũng có thể loại bỏ nó.
2.2.3. Phân mảnh thông điệp và tái lắp ráp.
Mỗi thông điệp DTLS phải phù hợp trong một lớp truyền tải gói tin đơn
giản. Tuy nhiên, những thông điệp handshake có khả năng lớn hơn kích thước
lớn nhất của bản ghi. Do đó, DTLS cung cấp một cơ chế phân mảnh một thông
điệp handshake thành nhiều bản ghi.
Khi truyền tải thông điệp handshake, người gửi chia thông điệp một loạt
N dãy dữ liệu liền kề. Các dãy này không được lớn hơn kích thước lớn nhất của
một mảnh và phải cùng nhau chứa toàn bộ thông điệp handshake. Các dãy
không được chồng lên nhau. Người gửi sau đó tạo ra N thông điệp handshake có
cùng giá trị message_seq với thông điệp handshake ban đầu. Mỗi thông điệp
mới được đánh nhãn với fragment_offset và fragment_length. Tổng chiều dài
của tất cả thông điệp giống với chiều dài của thông điệp ban đầu. Một thông
điệp không bị phân mảnh là một trường hợp suy thoái với fragment_offset=0 và
fragment_length=length.
Khi việc triển khai DTLS nhận một mảnh thông điệp handshake, nó phải
cho mảnh vào hàng đợi đến khi nó có toàn bộ thông điệp handshake. Việc triển
khai DTLS phải có khả năng điều khiển các dãy mảnh chồng nhau. Điều này
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ỏ
hơn xuyên suốt việc tìm kiếm MTU.
Lưu ý rằng giống như TLS, nhiều thông điệp handshake có thể bị đặt trên
những bản ghi DTLS giống nhau, DTLS cung cấp một room và chúng cùng một
lần gửi đi. Do đó, có hai cách được chấp nhận để đóng gói hai thông điệp DTLS
vào cùng một gói dữ liệu: trong một bản ghi tương tự hoặc trong những bản ghi
khác biệt.
2.2.4. Timeout và truyền lại.
Các thông điệp DTLS được nhóm lại trong cùng một dãy để gửi đi như sơ
đồ dưới đây. Mặc dù mỗi lần gửi có thể gồm một số thông điệp. Chúng nên được
xem như là một khối cho mục đích của thời gian chờ và truyền lại.
Client
------
Server
------
15
ClientHello
-------->
<-------
ClientHello
HelloVerifyRequest
Flight 2
-------->
<-------Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished
Flight 1
Flight 3
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
ServerHelloDone
\
\
Flight 4
/
/
\
\
Flight 5
/
-------->
<--------
/
[ChangeCipherSpec]
Finished
\ Flight 6
/
Figure 1. Message flights for full handshake
Client
-----ClientHello
Server
------------->
<-------[ChangeCipherSpec]
Finished
Flight 1
ServerHello
[ChangeCipherSpec]
Finished
-------->
\
Flight 2
/
\Flight 3
/
Figure 2. Message flights for session-resuming handshake
(no cookie exchange)
DTLS sử dụng một cơ chế timeout và truyền lại đơn giản với tình trạng
của máy. Bởi vì DTLS clients gửi thông điệp đầu tiên (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,
nhưng với những bộ đệm trống và không có bộ đế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 3. DTLS timeout and retransmission state machine
Trạng thái máy có 3 trạng thái cơ bản.
Trong trạng thái PREPARING, việc triển khai bất kỳ tính toán nào cũng là
cẩn thiết để chuẩn bị cho các thông điệp của lần gửi tiếp theo. Sau đó chúng
được đưa vào bộ đệm để vào trạng thái SENDING.
Trong trạng thái SENDING, thực hiện truyền các thông điệp lấy từ bộ
đệm. Khi thông điệp đã được gửi, việc triển khai sau đó đi vào trạng thái
FINISHED nếu như đó là lần gửi cuối cùng trong handshake. Hoặc, nếu việc
triển khai mong đợi nhận được nhiều thông điệp hơn, nó sẽ đặt một bộ đếm thời
gian truyền lại và sau đó đi vào trạng thái WAITING.
Có 3 cách để thoát khỏi trạng thái WAITING:
17
1. Bộ đếm thời gian truyền lại kết thúc: các việc thực hiện đến
trạng thái SENDING, nơi mà nó sẽ thực hiện truyền lại, thiết lập
bộ đếm thời gian truyền lại, và quay lại trạng thái WAITING.
2. Việc thực hiện đọc một lần truyền lại từ một cái tương đương:
việc chuyển đổi sang trạng thái SENDING, nơi mà nó gửi lại,
đặt lại bộ đếm thời gian truyền lại, và trở về trạng thái
WAITING. Cơ sở ở đây là nhận được một tin nhắn trùng lặp
giống như kết quả của việc hết thời gian trên cái tương đương và
do đó cho thấy rằng một phần của lần gửi trước đã bị mất.
3. Việc thực hiện nhận những thông điệp tiếp theo được gửi:
Nếu nó là lần gửi cuối của những thông điệp, việc thực hiện
được chuyển đến FINISHED. Nếu việc thực hiện cần một lần
gửi mới, nó sẽ chuyển đến trạng thái PREPARING. Việc đọc
một phần (một mẩu thông điệp hay một ít thông điệp trong lần
gửi) không gây ra quá trình chuyển đổi trạng thái hay đặt lại hẹn
giờ.
Bởi vì DTLS clients gửi thông điệp đầu tiên (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,
nhưng với bộ đệm trống và không có bộ đếm thời gian truyền lại.
Khi server mong muốn một rehandshake, nó chuyển từ FINISHED sang
PREPARING để gửi HelloRequest. Khi client nhận được HelloRequest, nó
chuyển từ FINISHED sang PREPARING để gửi ClientHello.
2.2.4.1. Giá trị bộ hẹn giờ.
Mặc dù giá trị bộ hẹn giờ là một lựa chọn của việc thực hiện, xử lý sai
thời gian có thể dẫn đến các vấn đề tắc nghẽn nghiêm trọng, ví dụ như nếu các
lời yêu cầu của DTLS hết giờ sớm và việc truyền lại quá nhanh trên đường dẫn
chật hẹp. Việc thực hiện nên sử dụng một giá trị bộ đếm thời gian ban đầu là 1
giây và 2 giá trị ở mỗi lần truyền lại. Lưu ý rằng nên sử dụng bộ hẹn giờ 1 giây
thay vì 3 giây mặc định để cải thiện độ trễ cho các ứng dụng nhạy cảm với thời
gian. Bởi vì DTLS chỉ sử dụng truyền lại cho handshake và không cho dataflow,
ảnh hưởng dẫn đến tắc nghẽn sẽ là tối thiểu.
Việc triển khai nên giữ lại giá trị bộ đếm thời gian hiện tại cho đến khi
việc truyền tải không xảy ra mất mát, tại thời điểm đó giá trị có thể được đặt lại
về giá trị ban đầu. Sau một thời gian dài nghỉ ngơi, không ít hơn 10 lần giá trị bộ
đếm thời gian hiện tại, việc triển khai có thể đặt lại bộ đếm thời gian về giá trị
ban đầu. Một tình huống mà điều vừa nói có thể xảy ra là khi một rehandshake
được sử dụng sau khi truyền dữ liệu đáng kể.
2.2.5. ChangeCipherSpec.
Giống như với TLS, thông điệp ChangeCipherSpec không phải là một
thông điệp handshake về mặt kỹ thuật nhưng phải được coi là một phần của lần
18
gửi tương tự như kết giao thông điệp Finished cho mục đích của timeout và
truyền lại.
2.2.6. Finished Messages.
Finished messages có định dạng giống như trong TLS. Tuy nhiên, để loại
bỏ độ nhạy cảm của việc phân mảnh, Finished MAC phải được tính toán như
nếu mỗi thông điệp handshake được gửi thì nó phải là một mảnh duy nhất. Lưu
ý rằng trong nhiều trường hợp việc trao đổi cookie được sử dụng, ClientHello và
HelloVerifyRequest ban đầu không được bao gồm trong Finished MAC.
2.2.7. Alert Messages.
Lưu ý rằng Alert Messages không được truyền lại trong tất cả các trường
hợp, ngay cả khi chúng xuất hiện trong bối cảnh handshake. Tuy nhiên, việc
thực hiện DTLS nên tạo một thông điệp cảnh báo mới nếu bản ghi lỗi được nhận
lần nữa.
2.3. Tóm tắt các cú pháp mới.
Phần này bao gồm một số thay đổi về cấu trúc dữ liệu giữa TLS 1.1 và
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<0..32>;
// New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
struct {
ProtocolVersion server_version;
opaque cookie<0..32>;
} HelloVerifyRequest;
3. CHÚ Ý BẢO MẬT
Tài liệu này mô tả một biến thể của TLS 1.1 vì vậy hầu hết những chú ý
về bảo mật sẽ giống như trên TLS 1.1. Chú ý về bảo mật bổ sung chính được
DTLS đưa ra là việc từ chối dịch vụ. DTLS bao gồm một sự trao đổi cookie
được 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 này vẫn dễ bị tấn công bởi DoS. Cụ thể
là, những dịch vụ mà không sử dụng việc trao đổi cookie có thể được sử dụng
như những bộ khuếch đại tấn công thậm chí nếu bản thân chúng chưa được trải
nghiệm DoS. Vì vậy, những máy chủ DTLS nên sử dụng sự trao đổi cookie trừ
khi có một lí do thuyết phục rằng sự khuếch đại không đe dọa đến môi trường
20
của chúng. Các client phải được chuẩn bị một sự trao đổi cookie với mọi
handshake.
4. MÔ PHỎNG HOẠT ĐỘNG CỦA DTLS ĐỂ KIỂM TRA
HANDSHAKE:
-Cố gắng thiết lập một mạng mô phỏng bằng Contiki cooja để kiểm tra
DTLS Handshake giữa DTLS-client và Server.
-Sử dụng “swismote” làm nền tảng đích và phát hành hiện tại của Contiki
và tinyDTLS.
-Theo ví dụ mặc định cung cấp trong tinyDTSL không thực hiện
Handshake . Ta phải thực hiện Handshake bằng tay từ tinyDTLS-client bằng
cách gọi:
“try_send (dtls_context, & dst);"
sau PROCESS_WAIT_EVENT_UNTIL (etimer_expired (&
et1));
-sau khi thực hiện mô phỏng Handshake bằng Contiki cooja thu được
Handshake theo kết quả sau:
21
22
23
KẾT LUẬN
Việc áp dụng DTLS trong giao thức UDP là một cách sử dụng và cải tiến
linh hoạt giao thứ TLS một cách hiệu quả để đáp ứng chạy trên UDP. Nó được
ứng dụng trên nhiều lĩnh vực như live stream, game online, … và những gì sử
dụng giao thức UDP. Trên đây là bài báo cáo tổng hợp những gì nhóm em tìm
hiểu về giao thức DTLS cũng như mô phỏng khách quan cách hoạt động của
giao thức này. Bài báo cáo còn nhiều thiếu sót chúng em mong nhận được sự
góp ý từ cô để có thể cải thiện trong những bài tiếp theo.
Nhóm chúng em xin chân thành cảm ơn.
24
TÀI LIỆU THAM KHẢO
1.
Trang web />
2.
Web
3.
Một số trang web khác.
25
