TLS là gì và nó hoạt động như thế nào?

Transport Layer Security (TLS) là một trong những giao thức bảo mật quan trọng nhất và được sử dụng rộng rãi. Nó bảo vệ một tỷ lệ đáng kể của dữ liệu được truyền trực tuyến. Nó nổi bật nhất được sử dụng để bảo mật dữ liệu di chuyển giữa trình duyệt web và trang web qua HTTPS, nhưng nó cũng có thể được sử dụng để bảo mật email và một loạt các giao thức khác.

TLS có giá trị vì nó đảm bảo bên kia trong kết nối là người mà họ nói, cho biết liệu dữ liệu có giữ được tính toàn vẹn ban đầu của nó hay không và cung cấp bảo mật thông qua mã hóa.

TLS sử dụng một loạt các thuật toán và sơ đồ khác nhau để thực hiện các mục đích này. Nó có vẻ phức tạp, nhưng bài viết này sẽ đề cập đến một khía cạnh tại một thời điểm để cung cấp cho bạn cái nhìn sâu sắc về cách TLS hoạt động để kết nối an toàn.

TLS làm gì?

Khi gửi thông tin trực tuyến, chúng tôi gặp phải ba vấn đề bảo mật chính:

• Làm thế nào chúng ta có thể biết liệu người mà chúng ta đang giao tiếp có thực sự là người họ nói không?
• Làm sao chúng ta có thể biết rằng dữ liệu đã bị giả mạo kể từ khi họ gửi nó?
• Làm cách nào chúng tôi có thể ngăn người khác xem và truy cập dữ liệu?

Những vấn đề này rất quan trọng, đặc biệt là khi chúng tôi đang gửi thông tin nhạy cảm hoặc có giá trị. TLS sử dụng một loạt các kỹ thuật mã hóa để giải quyết từng vấn đề trong ba vấn đề này. Cùng nhau, họ cho phép giao thức xác thực bên kia trong một kết nối, kiểm tra tính toàn vẹn của dữ liệu và cung cấp bảo vệ được mã hóa.

Hãy để đơn giản hóa mọi thứ và giả vờ rằng bạn đang cố gắng chuyển thông tin qua lại với một người bạn sống trên toàn quốc. Nếu thông tin nhạy cảm, bạn sẽ rất lo lắng về ba vấn đề chính được đề cập ở trên.

Bạn có thể chỉ cần gửi thư và hy vọng điều tốt nhất, đặc biệt nếu bạn nghi ngờ rằng thông tin liên lạc của bạn sẽ bị kẻ tấn công nhắm đến. Thay vào đó, bạn cần một hệ thống cho phép bạn xác minh rằng người nhận của bạn là hợp pháp, cách bạn có thể kiểm tra xem tin nhắn có bị thay đổi hay không và cách bảo vệ họ khỏi những con mắt tò mò.

TLS đáp ứng các yêu cầu này bằng cách sử dụng một số quy trình khác nhau. Nó bắt đầu với cái được gọi là Bắt tay TLS, đó là nơi diễn ra xác thực và các khóa được thiết lập.

Để trở về tương tự thư của chúng tôi, phần xác thực của TLS sẽ giống như gửi thư qua chuyển phát nhanh yêu cầu nhận dạng. Khi nhân viên chuyển phát nhanh chuyển thư, họ sẽ so sánh người ID ID với khuôn mặt của họ và xác minh xem người nhận có phải là người chính xác hay không.

Giai đoạn thiết lập chính sẽ giống như nếu thư của bạn chứa một nửa số pin mà bạn dự định sử dụng trong các lần liên lạc trong tương lai. Bạn sẽ yêu cầu người nhận của bạn đưa ra nửa sau của số và gửi cho bạn trong thư trả lời của họ.

Khi chuyển phát nhanh đã xác minh danh tính và số pin đã được thiết lập, bạn sẽ có mọi thứ bạn cần để gửi thông tin một cách an toàn. Trên thực tế, các giai đoạn này phức tạp hơn rất nhiều, nhưng chúng ta sẽ đến đó sau.

TLS trao đổi thông tin một cách an toàn với giao thức ứng dụng. Để thực hiện sự tương tự của chúng tôi, việc truyền dữ liệu một cách an toàn qua TLS sẽ giống như viết một tin nhắn và đưa nó vào một phong bì. Bạn sẽ viết chữ ký của mình trên con dấu, để nếu bức thư bị giả mạo, người nhận của bạn sẽ có thể nói bằng chữ ký bị rách (điều này thực sự được thực hiện bằng toán học, nhưng một lần nữa, chúng tôi sẽ trình bày sâu hơn sau).

Sau đó, bạn sẽ đặt chữ cái vào một hộp kim loại nhỏ có khóa kết hợp, đặt kết hợp làm số pin mà bạn cùng thiết lập với người nhận. Bạn sẽ gửi hộp thông qua chuyển phát nhanh kiểm tra nhận dạng khi các gói được giao. Người nhận của bạn sẽ trả lời theo cùng một cách và mọi thông tin liên lạc trong tương lai sẽ tuân theo các bước tương tự.

TLS giải quyết cả ba vấn đề của chúng tôi theo cách tương đối giống nhau. Chuyển phát nhanh phục vụ để xác thực người nhận và đảm bảo rằng hộp được gửi đến người dự định của nó. Hộp bị khóa đóng vai trò là một hình thức mã hóa, ngăn chặn bất kỳ ai trừ đối tác của bạn truy cập các chữ cái. Phong bì đã ký cho bạn biết liệu tin nhắn có bị giả mạo hay không.

Đây là một xấp xỉ rất thô sơ về những gì TLS làm. Thực tế, TLS diễn ra giữa máy khách và máy chủ, thay vì hai người đang gửi thư cho nhau. Sự tương tự chỉ là để cung cấp cho bạn một hình dung về những gì đang xảy ra và lý do đằng sau nó. Trong các phần sau, chúng tôi sẽ đề cập đến những gì thực sự xảy ra chi tiết.

TLS so với SSL

Khi đọc về TLS, bạn sẽ thường thấy đề cập đến SSL hoặc thậm chí là TLS / SSL. Lớp cổng bảo mật (SSL) là phiên bản cũ của TLS, nhưng nhiều người trong ngành vẫn đề cập đến TLS dưới biệt danh cũ. Bài viết này sẽ sử dụng thuật ngữ TLS xuyên suốt, nhưng điều quan trọng cần lưu ý là các tên thường được sử dụng thay thế cho nhau. Bạn có thể đọc thêm về SSL trong hướng dẫn của chúng tôi.

Lịch sử của TLS

Tất cả bắt đầu với sự cần thiết phải bảo đảm lớp vận chuyển. Như chúng tôi đã đề cập ở trên, tiền thân của TLS là SSL. Các phiên bản đầu tiên của SSL được phát triển vào những năm 1990 bởi Netscape, một công ty đã xây dựng một trong những trình duyệt web đầu tiên.

SSL 1.0 không bao giờ được phát hành vì nó chứa các lỗ hổng nghiêm trọng. Phiên bản 2.0 ra mắt với Netscape Navigator 1.1 vào năm 1995, tuy nhiên nó vẫn chứa một số sai sót nghiêm trọng. SSL 3.0 là phiên bản được thiết kế lại nhiều và xuất hiện vào năm 1996, với nhiều vấn đề bảo mật đã được giải quyết.

Năm 1996, IETF đã phát hành bản nháp SSL 3.0 trong RFC 6101. IETF đã thành lập một nhóm làm việc để chuẩn hóa SSL, công bố kết quả vào năm 1999 dưới dạng TLS 1.0. Nó đã được ghi nhận trong RFC 2246 và tiêu chuẩn hóa bao gồm một số thay đổi đối với giao thức gốc, cũng như thay đổi tên. Những sửa đổi này xuất hiện do kết quả của các cuộc đàm phán giữa Netscape, Microsoft và nhóm làm việc của IETF.

Năm 2006, IETF đã phát hành RFC 4346, tài liệu TLS 1.1. Phiên bản này chứa các điều khoản bảo mật mới và một số cập nhật khác. Phiên bản 1.2 được phát hành chỉ hai năm sau đó vào năm 2008. Nó bao gồm hỗ trợ cho các mật mã mã hóa được xác thực, một số thay đổi về cách sử dụng các hàm băm và nhiều cải tiến khác.

Phiên bản tiếp theo didn đến năm 2023, khi TLS 1.3 được xác định. Nó có một loạt các thay đổi, bao gồm bảo mật chuyển tiếp được thực thi, loại bỏ hỗ trợ cho các thuật toán yếu hơn và nhiều hơn nữa.

TLS 1.0 và 1.1 hiện không còn được sử dụng vào năm 2023, nhưng phiên bản 1.2 đang được sử dụng rộng rãi. Phiên bản 1.3 đang bắt đầu chứng kiến ​​sự gia tăng.

TLS: Các chi tiết kỹ thuật

TLS bao gồm nhiều yếu tố khác nhau. Phần cơ bản là giao thức ghi, giao thức cơ bản chịu trách nhiệm về cấu trúc bao trùm của mọi thứ khác.

Sơ đồ hiển thị ngăn xếp TLS. Ngăn xếp giao thức TLS của Jeffreytedjosukmono. Được cấp phép theo Muff.

Giao thức bản ghi chứa năm giao thức con riêng biệt, mỗi giao thức được định dạng là Hồ sơ:

• Bắt tay – Giao thức này được sử dụng để thiết lập các tham số cho kết nối an toàn.
• Ứng dụng – Giao thức ứng dụng bắt đầu sau quá trình bắt tay và đó là nơi dữ liệu được truyền an toàn giữa hai bên.
• Thông báo – Giao thức cảnh báo được sử dụng bởi một trong hai bên trong kết nối để thông báo cho bên kia nếu có bất kỳ lỗi nào, sự cố ổn định hoặc thỏa hiệp tiềm năng.
• Thay đổi thông số kỹ thuật – Giao thức này được sử dụng bởi máy khách hoặc máy chủ để sửa đổi các tham số mã hóa. Nó rất đơn giản, vì vậy chúng tôi đã thắng sâu trong bài viết này.
• Nhịp tim – Đây là tiện ích mở rộng TLS cho phép một bên của kết nối biết liệu đồng đẳng của nó có còn sống hay không và ngăn tường lửa đóng các kết nối không hoạt động. Nó không phải là một phần cốt lõi của TLS, vì vậy chúng tôi sẽ bỏ qua nó trong hướng dẫn này.

Mỗi giao thức con này được sử dụng trong các giai đoạn khác nhau để truyền đạt thông tin khác nhau. Những điều quan trọng nhất cần hiểu là bắt tay và các giao thức ứng dụng, bởi vì chúng có trách nhiệm thiết lập kết nối và sau đó truyền dữ liệu một cách an toàn.

Giao thức bắt tay TLS

Đây là nơi kết nối được thiết lập một cách an toàn. Nó có vẻ phức tạp nếu bạn chưa quen với một số khái niệm, nhưng mỗi khái niệm này sẽ được đề cập sau trong bài viết nếu bạn cần tham khảo chúng.

Có ba loại bắt tay TLS cơ bản: bắt tay TLS cơ bản, các bắt tay TLS xác thực khách hàng và bắt tay viết tắt.

Cái bắt tay TLS cơ bản

Sơ đồ hiển thị quá trình bắt tay TLS. Bắt tay đầy đủ TLS 1.2 bởi F MeatGrinder. Được cấp phép theo Muff.

Trong kiểu bắt tay này, chỉ có máy chủ được xác thực và không phải máy khách. Nó bắt đầu với giai đoạn đàm phán, trong đó khách hàng gửi Xin chào khách hàng thông điệp. Phiên bản này chứa phiên bản TLS cao nhất mà máy khách hỗ trợ, bộ mật mã có thể, cho biết liệu nó có hỗ trợ nén, số ngẫu nhiên và một số thông tin khác không

Thông báo Hello Client được đáp ứng với một Xin chào máy chủ thông điệp. Phản hồi này chứa ID phiên, phiên bản giao thức, bộ mật mã và nén (nếu có đang được sử dụng) mà máy chủ đã chọn từ danh sách máy khách. Nó cũng bao gồm một số ngẫu nhiên khác nhau.

Nó phụ thuộc vào bộ mật mã đã được chọn, nhưng máy chủ thường sẽ làm theo điều này bằng cách gửi Chứng chỉ tin nhắn để xác thực. Điều này xác nhận danh tính của nó và chứa khóa công khai của nó.

Nếu trao đổi khóa tạm thời Diffie-Hellman hoặc trao đổi khóa ẩn danh Diffie-Hellman đang được sử dụng, thì điều này được theo sau bởi một Trao đổi khóa máy chủ thông điệp. Các phương pháp trao đổi khóa khác bỏ qua phần này. Khi máy chủ kết thúc với phần đàm phán, nó sẽ gửi một Máy chủ Xin chào thông điệp.

Bây giờ, nó lại là khách hàng. Tùy thuộc vào bộ mật mã được chọn, nó sẽ gửi Trao đổi khóa khách hàng thông điệp. Điều này có thể chứa khóa công khai hoặc bí mật sớm hơn, được mã hóa bằng khóa công khai của máy chủ.

Cả hai bên sau đó sử dụng các số ngẫu nhiên và bí mật sớm hơn để đưa ra một bí mật chính. Các khóa được lấy từ bí mật chính, sau đó được sử dụng để xác thực và mã hóa thông tin liên lạc.

Khách hàng sau đó gửi một Thay đổi thông số kỹ thuật thông điệp. Điều này cho máy chủ biết rằng các thông báo sau sẽ được xác thực và mã hóa (mặc dù đôi khi mã hóa có thể không được sử dụng).

Sau đó, khách hàng theo dõi điều này với một Đã kết thúc tin nhắn được mã hóa và cũng chứa Mã xác thực thư (MAC) để xác thực. Máy chủ giải mã thông báo này và xác minh MAC. Nếu bất kỳ quá trình nào trong số này không thành công, thì kết nối sẽ bị từ chối.

Bây giờ, nó đã chuyển sang máy chủ Lần lượt gửi Thay đổi thông số kỹ thuật tin nhắn, cũng như một Đã kết thúc tin nhắn có cùng nội dung như trên. Sau đó, khách hàng cũng cố gắng giải mã và xác minh nội dung. Nếu điều này được hoàn thành thành công, bắt tay kết thúc. Tại thời điểm này, giao thức ứng dụng được thiết lập. Dữ liệu sau đó có thể được trao đổi an toàn theo cách tương tự như Đã kết thúc tin nhắn từ phía trên, với xác thực và mã hóa tùy chọn.

Bắt tay TLS xác thực khách hàng

Cái bắt tay này rất giống với cái bắt tay TLS cơ bản, nhưng khách hàng cũng được xác thực. Sự khác biệt chính là sau khi máy chủ gửi nó Chứng chỉ tin nhắn, nó cũng gửi một Yêu cầu chứng chỉ tin nhắn, yêu cầu chứng chỉ khách hàng. Khi máy chủ kết thúc, máy khách sẽ gửi chứng chỉ của nó trong Chứng chỉ thông điệp.

Sau đó khách hàng gửi nó Trao đổi khóa khách hàng tin nhắn, giống như trong cái bắt tay TLS cơ bản. Tiếp theo là Xác nhận chứng chỉ tin nhắn, bao gồm chữ ký số của khách hàng. Vì nó được tính từ khóa riêng của máy khách, máy chủ có thể xác minh chữ ký bằng khóa chung được gửi như một phần của chứng chỉ kỹ thuật số máy khách. Phân con lại của Bắt tay TLS xác thực khách hàng theo cùng dòng với bắt tay TLS cơ bản.

Bắt tay TLS viết tắt

Khi một cái bắt tay đã diễn ra, TLS cho phép phần lớn quá trình được cắt bỏ bằng cách sử dụng một cái bắt tay viết tắt thay thế. Những cái bắt tay này sử dụng ID phiên để liên kết kết nối mới với các tham số trước đó.

Một cái bắt tay viết tắt cho phép cả hai bên tiếp tục kết nối an toàn với cùng một thiết lập đã được đàm phán trước đó. Bởi vì một số mật mã thường tham gia vào việc bắt đầu một cái bắt tay có thể khá nặng về tài nguyên tính toán, điều này giúp tiết kiệm thời gian và giúp kết nối dễ dàng hơn.

Quá trình bắt đầu với Xin chào khách hàng thông điệp. Nó rất giống với tin nhắn Hello Hello trước đó, nhưng nó cũng chứa ID phiên từ kết nối trước đó. Nếu máy chủ biết ID phiên, nó bao gồm nó trong Xin chào máy chủ thông điệp. Nếu nó không nhận ra ID phiên, nó sẽ trả về một số khác và bắt tay TLS đầy đủ sẽ phải diễn ra.

Nếu máy chủ nhận ra ID phiên, thì Chứng chỉ và Trao đổi khóa các bước có thể được bỏ qua. Các Thay đổi thông số kỹ thuật và Đã kết thúc tin nhắn được gửi theo cách tương tự như bắt tay TLS cơ bản được hiển thị ở trên. Khi khách hàng đã giải mã tin nhắn và xác minh MAC, dữ liệu có thể được gửi qua kết nối TLS an toàn.

Ngoài ra còn có một tiện ích mở rộng TLS cho phép các kết nối được nối lại với vé phiên thay vì ID phiên. Máy chủ mã hóa dữ liệu về phiên và gửi nó đến máy khách. Khi khách hàng muốn tiếp tục kết nối này, nó sẽ gửi vé phiên tới máy chủ, giải mã nó để tiết lộ các tham số.

Vé phiên không được sử dụng thường xuyên vì chúng yêu cầu gia hạn. Mặc dù vậy, chúng có thể có lợi trong một số trường hợp nhất định, vì máy chủ không phải là lưu trữ.

Giải nén cái bắt tay TLS

Ba bước quan trọng nhất của bắt tay bao gồm:

• các tham số được chọn,
• nó tiến hành xác thực, và
• các khóa được thiết lập.

Hãy để che cho chúng chi tiết hơn một chút để bạn có thể hiểu những gì thực sự xảy ra.

Những thông số

Khi bắt đầu bắt tay, khách hàng và máy chủ sẽ thương lượng các tham số của kết nối bằng thỏa thuận chung. Đầu tiên trong số này là phiên bản của TLS sẽ được sử dụng. Đây là phiên bản cao nhất mà cả hai bên hỗ trợ, có xu hướng an toàn nhất.

Các bên cũng quyết định thuật toán trao đổi khóa nào họ sẽ sử dụng để thiết lập khóa chính. Hàm băm, thuật toán mã hóa và phương thức nén cũng được thỏa thuận trong giai đoạn này. Chúng sẽ được đề cập chi tiết khi chúng ta thảo luận về Giao thức ứng dụng sau đó trong bài viết.

Xác thực: Chứng thư số

Xác thực là một phần quan trọng trong việc đảm bảo một kênh liên lạc, bởi vì nó cho phép cả hai bên biết rằng họ thực sự đang nói chuyện với người mà họ nghĩ là họ chứ không phải là kẻ mạo danh. Trong TLS và nhiều cơ chế bảo mật khác, điều này đạt được với cái được gọi là chứng thư số.

Chứng thư số là tài liệu điện tử hiển thị liên kết giữa một cá nhân hoặc tổ chức và khóa chung của họ. Liên kết này được xác thực bởi cơ quan chứng nhận (CA), một tổ chức đáng tin cậy xác minh rằng hai thực sự có liên quan với nhau, sau đó sử dụng danh tiếng của chính mình để trao niềm tin cho chứng chỉ.   

Cấp độ chứng chỉ khác nhau đại diện cho mức độ tin cậy khác nhau. Điều quan trọng cần biết là nếu máy khách hoặc máy chủ có chứng chỉ hợp lệ và đáng tin cậy, thì thật hợp lý khi cho rằng khóa công khai là hợp pháp và bạn không giao dịch với kẻ tấn công.

Một lưu ý về khóa công khai

Mã hóa khóa công khai (còn được gọi là mã hóa bất đối xứng) là một phần quan trọng của mật mã, và nó được sử dụng rộng rãi trong các khía cạnh khác nhau của TLS. Đây là một mồi nhanh cho những người không quen với cách thức hoạt động của nó.

Giải thích ngắn gọn là Mật mã khóa công khai sử dụng một cặp khóa để mã hóa và giải mã, thay vì chỉ một khóa duy nhất. Người gửi sử dụng khóa công khai người nhận dự định của họ để mã hóa dữ liệu. Một khi nó đã được mã hóa, nó chỉ có thể được giải mã bằng khóa riêng phù hợp với người nhận. Tất nhiên, khóa chung có thể được chia sẻ công khai trong khi khóa riêng phải được giữ bí mật.

Mã hóa khóa công khai cho phép các bên chia sẻ thông tin một cách an toàn, ngay cả khi họ chưa bao giờ gặp hoặc có cơ hội trao đổi khóa trước đó. Nó thực hiện điều này thông qua một số thuộc tính duy nhất của số nguyên tố. Bạn có thể tìm hiểu thêm trong bài viết của chúng tôi về mã hóa khóa công khai.

Thiết lập một bí mật tổng thể

Như chúng ta đã thấy ở trên khi chúng ta thảo luận về quá trình bắt tay TLS cơ bản, sau khi một bên (hoặc cả hai bên) chứng minh danh tính của mình bằng chứng nhận công khai, Bước tiếp theo là thiết lập bí mật chính, còn được gọi là bí mật chung. Bí mật chính là cơ sở để lấy các khóa được sử dụng để mã hóa và kiểm tra tính toàn vẹn của dữ liệu được truyền giữa hai bên.

Bắt tay TLS có thể sử dụng một số cơ chế khác nhau để chia sẻ bí mật này một cách an toàn. Chúng bao gồm RSA, một số loại khác nhau của trao đổi khóa Diffie-Hellman, PSK, Kerberos và các loại khác. Mỗi cái đều có những ưu điểm và nhược điểm riêng, chẳng hạn như cung cấp bí mật về phía trước, nhưng những khác biệt này nằm ngoài phạm vi của bài viết này.

Quá trình chính xác sẽ phụ thuộc vào phương pháp trao đổi khóa nào đã được chọn, nhưng nó tuân theo các bước thô được đề cập trong Cái bắt tay TLS cơ bản phần.

Bí mật tiền tố được lấy theo phương pháp trao đổi khóa nào đã được chọn trước đó. Máy khách mã hóa bí mật sớm hơn với khóa công khai của máy chủ để gửi nó một cách an toàn qua kết nối.

Sau đó, cả máy khách và máy chủ đều sử dụng bí mật tiền tố và các số ngẫu nhiên mà chúng đã gửi khi bắt đầu liên lạc để đưa ra bí mật chính. Khi khóa chính đã được tính toán, nó được sử dụng để đưa ra bốn hoặc sáu khóa riêng biệt. Đây là những:

• Khách hàng viết khóa MAC – Khóa này được máy chủ sử dụng để kiểm tra tính toàn vẹn của dữ liệu được gửi bởi máy khách.
• Máy chủ viết khóa MAC – Khóa máy chủ ghi MAC được máy khách sử dụng để kiểm tra tính toàn vẹn của dữ liệu được gửi bởi máy chủ.
• Khóa mã hóa của khách hàng – Máy chủ sử dụng khóa này để mã hóa dữ liệu được gửi bởi khách hàng.
• Máy chủ viết mã khóa – Máy khách sử dụng khóa này để mã hóa dữ liệu được gửi bởi máy chủ.
• Khách hàng viết khóa IV – Khóa IV ghi của máy khách được máy chủ sử dụng trong mật mã AEAD, nhưng không sử dụng khi các thuật toán trao đổi khóa khác được sử dụng.
• Máy chủ viết khóa IV – Tương tự, khóa này được ứng dụng khách sử dụng trong mật mã AEAD, nhưng không phải khi các thuật toán trao đổi khóa khác được sử dụng.

Việc thiết lập khóa chính là một phần quan trọng của bắt tay TLS, bởi vì nó cho phép cả hai bên của kết nối có được các khóa phái sinh an toàn có thể được sử dụng cho cả xác thực và mã hóa. Các khóa riêng biệt được sử dụng cho cả hai quá trình để phòng ngừa.

Khi các khóa xác thực và mã hóa đã được lấy, chúng được sử dụng để bảo vệ cả hai Đã kết thúc tin nhắn, cũng như hồ sơ được gửi qua giao thức ứng dụng.

Giao thức ứng dụng

Khi kết nối an toàn đã được thiết lập bằng bắt tay TLS, giao thức ứng dụng được sử dụng để bảo vệ dữ liệu được truyền. Nó có thể được cấu hình để sử dụng một loạt các thuật toán để phù hợp với các kịch bản khác nhau.

Thuật toán xác thực

Tính toàn vẹn của tin nhắn có thể được kiểm tra bằng nhiều thuật toán khác nhau. Bao gồm các:

• HMAC-MD5
• HMAC-SHA1
• HMAC-SHA2
• AEAD

Để chứng minh tính toàn vẹn của dữ liệu được gửi, người gửi chạy thông tin thông qua hàm băm để trả về một chuỗi ký tự duy nhất. Đây là những công thức đặc biệt sẽ luôn trả về cùng một kết quả bất cứ khi nào chúng nhận được cùng một đầu vào.

Người gửi ký dữ liệu này bằng khóa riêng của họ để tạo thành cái được gọi là chữ ký số, Chữ ký số sau đó được đính kèm vào tin nhắn và gửi cho người nhận. Để kiểm tra xem dữ liệu có giữ được tính toàn vẹn của nó hay không và đã bị giả mạo, người nhận giải mã hàm băm bằng khóa công khai của người gửi. Sau đó, họ sử dụng cùng hàm băm trên dữ liệu đã được gửi. Người nhận sau đó so sánh hai giá trị.

Nếu chúng giống nhau, điều đó có nghĩa là dữ liệu đã không bị thay đổi kể từ khi được người gửi ký tên. Nếu chúng khác nhau, có khả năng dữ liệu đã bị giả mạo hoặc có một số lỗi khác.

Đó là phiên bản ngắn về cách các hàm băm có thể được sử dụng để hiển thị tính toàn vẹn của dữ liệu. Nếu bạn muốn hiểu sâu hơn, hãy xem bài viết của chúng tôi về mã hóa, muối và băm.

Thuật toán mã hóa

TLS sử dụng mã hóa khóa đối xứng để cung cấp bảo mật cho dữ liệu mà nó truyền. Không giống như mã hóa khóa công khai, chỉ một khóa được sử dụng trong cả quá trình mã hóa và giải mã. Khi dữ liệu đã được mã hóa bằng thuật toán, nó sẽ xuất hiện dưới dạng mớ lộn xộn của bản mã. Miễn là một thuật toán thích hợp được sử dụng, những kẻ tấn công sẽ không thể truy cập dữ liệu thực tế, ngay cả khi chúng chặn nó.

TLS có thể sử dụng nhiều thuật toán khác nhau, chẳng hạn như Camellia hoặc ARIA, mặc dù phổ biến nhất là AES.

Nén

Nén là quá trình mã hóa dữ liệu để làm cho nó chiếm ít không gian hơn. TLS hỗ trợ nén nếu cả hai bên của kết nối quyết định sử dụng nó. Mặc dù có khả năng này, nhưng thường nên tránh sử dụng TLS để nén dữ liệu, đặc biệt là từ cuộc tấn công CRIME (xem phần Các vấn đề bảo mật của TLS phần bên dưới) đã được tìm thấy để có thể tận dụng dữ liệu nén để chiếm quyền điều khiển phiên.

Đệm

Đệm thêm dữ liệu bổ sung vào một tin nhắn trước khi nó được mã hóa. Nó có một quy trình mã hóa phổ biến được sử dụng để giúp ngăn chặn các gợi ý trong cấu trúc dữ liệu được mã hóa từ bỏ ý nghĩa thực sự của nó. TLS thường áp dụng phần đệm PKCS # 7 cho các bản ghi trước khi chúng được mã hóa.

Giao thức cảnh báo

Nếu kết nối hoặc bảo mật không ổn định, bị xâm phạm hoặc xảy ra lỗi nghiêm trọng, giao thức cảnh báo cho phép người gửi thông báo cho bên kia. Những tin nhắn này có hai loại, hoặc cảnh báo hoặc gây tử vong. Một thông báo cảnh báo chỉ ra rằng phiên không ổn định và cho phép người nhận xác định liệu phiên có nên được tiếp tục hay không.

Một thông báo gây tử vong cho người nhận rằng kết nối đã bị xâm phạm hoặc xảy ra lỗi nghiêm trọng. Người gửi nên đóng kết nối sau khi họ gửi tin nhắn. Giao thức cảnh báo cũng chứa thông tin về những gì gây ra vấn đề kết nối cụ thể. Điều này có thể bao gồm những thứ như lỗi giải mã, cơ quan chứng nhận không xác định, tham số bất hợp pháp và nhiều hơn nữa.

TLS & mô hình OSI

Mô hình OSI là một cách để khái niệm hóa và tiêu chuẩn hóa cách chúng ta nhìn vào các hệ thống và giao thức truyền thông khác nhau. Điều quan trọng cần lưu ý là nó chỉ là một mô hình và một số giao thức của chúng tôi không phù hợp với nó.

OSI có bảy lớp riêng biệt cho thấy các mức mà giao thức hoạt động, tuy nhiên, TLS không phù hợp với bất kỳ ai. Nó chảy qua một giao thức vận chuyển khác như TCP, nghĩa là nó ở trên lớp thứ tư, lớp vận chuyển. Nó được sử dụng nổi bật nhất như một lớp vận chuyển, nhưng vì nó tiến hành bắt tay, nên điều này có nghĩa là nó là một phần của lớp trình bày hoặc lớp ứng dụng.

Như bạn có thể thấy, TLS chỉ đơn giản là không tuân thủ mô hình OSI. Điều này không có nghĩa là TLS bị hỏng hoặc sai, nếu có bất cứ điều gì, nó chỉ cho thấy rằng mô hình OSI bị lỗi và không thể giải thích cho tất cả các giao thức truyền thông của chúng tôi.

Sử dụng TLS

TLS được sử dụng để bảo đảm một tỷ lệ đáng kể trong giao tiếp trực tuyến của chúng tôi. Thông thường nó được thực hiện trên các giao thức như Giao thức điều khiển truyền (TCP), nhưng nó cũng có thể được sử dụng trong Giao thức kiểm soát tắc nghẽn gói dữ liệu (DCCP) và Giao thức gói dữ liệu người dùng (UDP).

Nó có thể bảo mật các giao thức như HTTP, SMTP, FTP, XMPP và NNTP, cũng như những người khác Ứng dụng phổ biến nhất là Bảo mật Giao thức Truyền Siêu văn bản (HTTPS), bảo vệ kết nối giữa trình duyệt web và trang web. Bạn có thể biết khi nào HTTPS đang được sử dụng để bảo mật kết nối trực tuyến của bạn, bởi vì một biểu tượng khóa nhỏ màu xanh lá cây sẽ xuất hiện ở bên trái của URL ở đầu trình duyệt của bạn.

TLS cũng có thể được sử dụng để xây dựng VPN, chẳng hạn như trong OpenConnect và OpenVPN. Nó sử dụng khả năng mã hóa và xác thực của mình để tạo thành một đường hầm có thể kết nối máy chủ và mạng với nhau. Các công nghệ VPN dựa trên TLS như OpenVPN có lợi thế hơn các lựa chọn thay thế như IPsec, vì OpenVPN không được biết là có bất kỳ vấn đề bảo mật nghiêm trọng nào. Các VPN này cũng có thể dễ dàng hơn để cấu hình.

Một công dụng khác của nó là email an toàn thông qua STARTTLS. Khi TLS được triển khai, nó ngăn kẻ tấn công có thể truy cập thư khi chúng di chuyển giữa các máy chủ thư.

Vấn đề bảo mật TLS

Giống như hầu hết các giao thức, TLS đã có một số lỗ hổng trong quá khứ và các cuộc tấn công lý thuyết chống lại các triển khai khác nhau của nó. Mặc dù vậy, các phiên bản mới nhất được coi là an toàn cho các mục đích thực tế.

Các phiên bản trước đây, chẳng hạn như SSL 2.0 và 3.0 (và TLS 1.0, về cơ bản giống như SSL 3.0) có nhiều lỗi bảo mật, nhưng vì chúng là các giao thức cũ và không dùng nữa, chúng tôi đã giành được chi tiết. Thay vào đó, bạn nên sử dụng TLS 1.2 và 1.3 để bảo mật các kết nối của mình.

Các phiên bản mới hơn của TLS có nhiều nâng cấp khiến nó ít bị tổn thương hơn SSL. Mặc dù vậy, giao thức vẫn có các vấn đề bảo mật sau:

Tấn công đàm phán lại

Một trong những tính năng của TLS là nó cho phép các cặp máy khách và máy chủ đàm phán lại các tham số của kết nối hiện có của chúng. Vào năm 2009, người ta đã phát hiện ra rằng điều này có thể bị những kẻ tấn công khai thác để họ có thể tiêm lưu lượng truy cập để làm cho nó trông giống như nó đến từ máy khách. Máy chủ sẽ chấp nhận yêu cầu là hợp pháp, điều đó có nghĩa là những kẻ tấn công có khả năng đang thao túng các tin nhắn gửi đi.

Cuộc tấn công này không cho phép kẻ tấn công nhìn thấy phản ứng, nhưng nó vẫn có khả năng gây sát thương. Một phần mở rộng sẽ ngăn chặn các cuộc tấn công này hiện đang là một tiêu chuẩn được đề xuất.

QUÁI THÚ

Cuộc tấn công khai thác trình duyệt chống lại SSL / TLS (BEAST) lần đầu tiên được các nhà nghiên cứu phát hiện vào năm 2011. Nó lợi dụng lỗ hổng chuỗi khối mật mã trong TLS, có thể được sử dụng để giải mã tin nhắn. Cuộc tấn công này chỉ ảnh hưởng đến TLS 1.0, đây là phiên bản cũ và yếu hơn của giao thức. Mặc dù nó sẽ không được dùng nữa cho đến năm 2023, nhưng người dùng nên sử dụng phiên bản 1.2 và 1.3 thay thế.

Thời gian tấn công

Các cuộc tấn công kênh bên này phân tích thời gian để thuật toán chạy trong bao lâu, sau đó sử dụng thông tin đó để làm việc ngược và tìm ra khóa. Vào năm 2013, cuộc tấn công Lucky Thirteen đã được phát hiện để thúc đẩy cả cuộc tấn công thời gian và cuộc tấn công sấm sét trong khi mã xác thực tin nhắn (MAC) đang được kiểm tra. Cuộc tấn công này có thể được sử dụng để phá vỡ thuật toán TLS, mặc dù nó không được coi là nguy hiểm đối với phần lớn người dùng TLS.

TỘI ÁC & VI PHẠM

Cuộc tấn công CRIME hoạt động chống lại một loạt các giao thức. Khi dữ liệu đã được nén, nó có thể gợi ra nội dung từ cookie xác thực. Thông tin này có thể được sử dụng để chiếm quyền điều khiển phiên. Mặc dù nó ảnh hưởng đến một số giao thức, cuộc tấn công đặc biệt đáng lo ngại khi nén HTTP đang được sử dụng, vì không có chiến lược giảm thiểu hiệu quả.

Vào năm 2013, việc khai thác và kiểm tra trình duyệt thông qua quá trình nén thích ứng của siêu văn bản (BREACH) đã được tìm thấy ảnh hưởng đến việc nén HTTP theo cách tương tự. Phiên bản tấn công này có thể khôi phục địa chỉ email và dữ liệu có giá trị khác được mã hóa bằng TLS. Cuộc tấn công BREACH có thể được giảm thiểu bằng cách vô hiệu hóa nén HTTP hoặc sử dụng các kỹ thuật như bảo vệ giả mạo yêu cầu chéo trang (CSRF).

Tấn công hạ cấp

Đây là các cuộc tấn công lừa máy chủ sử dụng các phiên bản TLS trước đó và kém an toàn hơn. Những kẻ tấn công có thể sử dụng các kỹ thuật này để đàm phán việc sử dụng các trao đổi và mật mã khóa kém an toàn hơn. Cuộc tấn công Logjam là một ví dụ điển hình vì nó có thể khiến các máy chủ dễ bị tổn thương sử dụng Diffie-Hellman 512 bit, yếu. Những kẻ tấn công sau đó có thể phá vỡ cơ chế trao đổi khóa này và trích xuất các khóa, cho phép chúng truy cập hoàn toàn vào phiên.

Đau lòng

Heartbleed là một lỗ hổng bảo mật đã vô tình được đưa vào thư viện mật mã OpenSSL vào năm 2012, nhưng không được công khai cho đến năm 2014. Bởi vì đây là cách triển khai TLS thường được sử dụng, nên nó đã gây ra thiệt hại đáng kể trên toàn cầu.

Một trong những nhà phát triển cho phần mở rộng nhịp tim TLS đã thêm một lỗ hổng đọc quá mức bộ đệm, cho phép một số dữ liệu bổ sung được phơi bày. Lỗi không được nhận khi mã được xem xét, dẫn đến một số cuộc tấn công đáng kể.

Do thư viện OpenSSL được triển khai rộng rãi, nên chi phí quốc tế để giảm thiểu vấn đề kết thúc khá tốn kém. Quản trị viên máy chủ phải cài đặt bản vá mới và tạo lại chứng chỉ và các cặp khóa có thể đã bị xâm phạm trong khoảng thời gian hai năm tồn tại lỗ hổng.

CHẾT CHÌM

RSA giải mã với cuộc tấn công mã hóa lỗi thời và suy yếu (DROWN) đã được công bố vào năm 2016 và nó tận dụng sự hỗ trợ của máy chủ cho SSL 2.0. Nó sử dụng một cuộc tấn công mã hóa được chọn vào các máy chủ vẫn hỗ trợ SSL 2.0, cũng như các cuộc tấn công có chung chứng chỉ khóa chung với một máy chủ khác hỗ trợ SSL 2.0.

Khi cuộc tấn công được công bố, nó có thể được khởi chạy với chi phí thiết lập ban đầu khoảng 18.000 đô la và khoảng 400 đô la cho mỗi cuộc tấn công riêng biệt. Khi cuộc tấn công DROWN thành công, nó có được các khóa phiên.

Cuộc tấn công có thể được giảm nhẹ bằng cách không chia sẻ chứng chỉ máy chủ. Nhóm OpenSSL cũng đã phát hành các bản vá loại bỏ hỗ trợ cho các giao thức và mật mã cũ hơn, nhưng chúng chỉ hoạt động nếu chứng chỉ máy chủ không được chia sẻ với các máy chủ khác hỗ trợ SSL 2.0.

PAC bất hạnh

Cuộc tấn công này đã được tìm thấy vào năm 2016. Nó tận dụng các điểm yếu được tìm thấy trong Giao thức tự động phát hiện Web Proxy (WPAD). Khi người dùng cố gắng truy cập trang web qua kết nối được mã hóa TLS, lỗ hổng có thể khiến URL hiển thị. Do URL đôi khi được gửi cho người dùng dưới dạng xác thực, cuộc tấn công Unholy PAC giúp kẻ tấn công có thể chiếm đoạt tài khoản của người dùng.

TLS có an toàn không?

Mặc dù có vẻ như có rất nhiều vấn đề bảo mật, nhưng thực tế là hầu hết trong số này là khá nhỏ và có thể hoặc đã được giảm nhẹ. Khi công nghệ tiến bộ, các lỗ hổng được phát hiện và các cuộc tấn công mới được phát triển, TLS sẽ tiếp tục gặp nhiều vấn đề về bảo mật hơn. Mặc dù vậy, hiện tại và trong tương lai gần, có vẻ như TLS vẫn sẽ là một trong những công cụ chính và đáng tin cậy nhất mà chúng tôi sử dụng để bảo vệ thế giới trực tuyến của mình.

Công nghệ kinh doanh an ninh mạng bởi TheDigitalArtist được cấp phép theo Muff