intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE

Đề tài: Kiến trúc SSL/TLS

Chia sẻ: Huỳnh Thị Thùy Dương | Ngày: | Loại File: DOC | Số trang:13

221
lượt xem
32
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Mời các bạn cùng tham khảo nội dung đề tài "Kiến trúc SSL/TLS" dưới đây để nắm bắt được những nội dung sơ lược về SSL/TLS, ứng dụng, bảo mật, cách viết mật mã, mã hóa khóa đối xứng, mã hóa không đối xứng,... Đây là tài liệu tham khảo hữu ích cho các bạn chuyên ngành công nghệ thông tin.

Chủ đề:
Lưu

Nội dung Text: Đề tài: Kiến trúc SSL/TLS

  1. Mục Lục :          Trang 1­ Giới thiệu sơ lược về SSL/TLS:        2 2­ Ứng dụng:        3 3­ Bảo mật:        3 4­ Cách viết mật mã (Cryptography) :        4 5­ Mã hóa khóa đối xứng( secret key):        4 6­ Mã hóa không đối xứng(Asymmetric key encryption):        5 7­ Bảng tóm tắt(Digests):        6 8­ Chứng chỉ( Certificates):        6 9­ Lỗ hổng bảo mật của SSL:        7 A­ Hướng tấn công số 1 :         8 B­ Hướng tấn công số 2 :         9 C­ Hướng tấn công số 3 :       11 1
  2. 1­Giới thiệu sơ lược về SSL/TLS: SSL   (Secure   Socket   Layer)   là   giao   thức   được   phát   triển   bởi   Netscape.Version  1.0 không  được  công khai,  version  2.0  được  phát hành  tháng 2 năm 1995 nhưng vẫn có nhiều lỗ hổng về bảo mật nên SSL version  3.0 được phát hành vào năm 1996. SSL:   là một  giao  thức  sử  dụng rộng rãi cho  truyền  đạt thông  tin trong  mạng.Giao thức SSL dự phòng dịch vụ tiếp theo cho ứng dụng của mạng: Data privacy: Client/Server session thành các mật mã. Client authentication: Server có thể kiểm tra sự đồng nhất của Client. Server authentication: Client có thể kiểm tra sự đồng nhất của Server. Message integrity(tính nguyên vẹn của gói tin) : Data không thể  sửa   trong khi truyền. TLS 1.0 (Transport Layer Security) lần đầu tiên được định nghĩa trong RFC  2246 trong Tháng 1 năm 1999 như là một nâng cấp từ SSL v3.0. Như đã nêu   trong RFC, sự  khác biệt  này giữa  các  giao  thức SSL  3.0 là không  đáng  kể..Nó dùng nhiều các thuật toán “cryptographic”. TLS v1.1 đã được cập nhật từ  v 1.0 trong RFC 4346 trong tháng 4 năm  2006. Phiên bản này có 1 số khác biệt: Được   bảo   vệ   chống   lại   tấn   công   Cipher   Block   Chaining   (CBC). Khởi tiềm ẩn Initialization Vector (IV) đã được thay thế bằng một IV  rõ   ràng. Thay đổi trong giải quyết các lỗi padding. Hỗ   trợ   cho   IANA   đăng   ký   của   các   thông   số. TLS v1.2 được cập nhật trong RFC 5246 tháng 4 ,2008. Phiên bản này dựa  trên những đặc điểm kỹ thuật của v1.1, sự khác biệt lớn bao gồm: Sự   kết   hợp   MD5/SHA­1   trong   PseudoRandom   Function   (PRF)   đã  được   thay   thế   bằng   những   thuật   toán   mật   mã­bộ­PRFs   định. Sự kết hợp MD5/SHA­1 trong kỹ thuật số các nguyên tố đã ký được   thay thế  bằng một băm duy nhất, xác định trong một lĩnh vực mới. Nâng cao tại các khách hàng và khả  năng của máy chủ  để  xác định   những   thuật   toán   băm   và   chữ   ký   của   họ   sẽ   chấp   nhận. Mở rộng hỗ trợ cho sự mật mã xác thực. 2
  3. Mở   rộng   định  nghĩa   TLS  và   Advanced   Encryption  Standard  (AES)  CipherSuites được thêm vào. 2­Ứng dụng: Trong các  ứng dụng thiết kế, TLS thường được thực hiện trên đầu  trang của bất kỳ  giao thức vận tải tầng nào, đóng gói  ứng dụng giao thức  cụ thể như HTTP, FTP, SMTP, NNTP, và XMPP. Một sử  dụng nổi bật của TLS là để  bảo vệ  World Wide Web lưu lượng   vận   chuyển   bằng   HTTP   để   hình   HTTPS.   Đáng   chú   ý   là   các   ứng   dụng  thương mại điện tử  và quản lý tài sản. Ngày càng nhiều, các Simple Mail  Transfer Protocol (SMTP) cũng được bảo vệ bởi TLS (RFC 3207). Các ứng   dụng này sử dụng giấy chứng nhận công chính để xác minh nhận dạng của  thiết bị đầu cuối. TLS có một số lợi thế vốn có trong tường lửa và NAT traversal mà làm cho   nó   dễ   dàng   hơn   để   quản   trị   cho   quần   thể   truy   cập   lớn   từ   xa   . TLS   cũng   là   một   phương   pháp   tiêu   chuẩn   để   bảo   vệ   Session   Initiation  Protocol (SIP)  ứng dụng tín hiệu.  TLS có thể  được sử  dụng để  cung cấp  chứng thực và mã hoá của tín hiệu SIP kết hợp với VoIP và SIP khác dựa   trên ứng dụng . 3­ Bảo mật: TLS   /   SSL   có   một   loạt   các   biện   pháp   bảo   mật:      Các khách hàng có thể sử dụng quyền hạn của giấy chứng nhận (CA's)   khóa công khai    để  xác nhận chữ ký số  của CA trên chứng chỉ  máy chủ.   Nếu các chữ ký số có thể được xác minh, khách hàng chấp nhận chứng chỉ  máy chủ như là một chứng chỉ hợp lệ phát hành bởi một CA tin cậy.      Các khách hàng xác minh rằng CA phát hành là vào danh sách các CAs tin   cậy.      Các khách hàng sẽ kiểm tra giấy chứng nhận thời gian hiệu lực của máy  chủ. Quá trình thẩm định dừng lại nếu ngày hiện tại và thời gian vượt quá  thời   hạn   hiệu   lực.      Đánh số tất cả các bản ghi ứng dụng với một trình tự và sử dụng dãy số  này trong Message Authentication Codes (MACs).          Một  gói  thư   trao   đổi  thông  tin  kết  thúc  bắng  việc  bắt  tay  trả  lời  “Finished” giữa cả hai đối tượng trao đổi thông tin với nhau. 3
  4.      Một hàm ngẫu nhiên chia dữ liệu đầu vào ra một nửa và mỗi một bộ xử  lý với độ  khó hàm hashing(MD5 và SHA­1), thì XORs của chúng sẽ  cùng  nhau tạo MAC.Chúng sẽ  có bảo vệ  dự  phòng nếu thuật toán ở  đây có thể  bị công kích được.       SSL v3 được cải tiến trên SSLv2 nhờ được thêm vào cơ sở mã hóa của   SHA­1,và nâng cấp them xác thực của chứng chỉ(CA).Cải tiến thêm trong   SSLv3 bao gồm luồng giao thức bắt tay và tăng thêm việc chống đỡ  lại   việc tấn công “man­in­the­middle” 4­Cách viết mật mã (Cryptography) :        Mật mã là thuật ngữ ám chỉ để chuyển một thông điệp mà chỉ có người   nhận mới có thể  độc tin nhắn. Mật mã học cũng được sử  dụng để  xác  minh người gửi tin nhắn, và để xác minh một tin nhắn không được sửa đổi  trong quá trình truyền.         SSL sử  dụng thuật toán mã hóa khác nhau để  đảm bảo thông tin liên  lạc an toàn. Có bốn khái niệm mã hóa được sử dụng bởi SSL: Mã hóa khóa đối xứng( khóa bí mật) Mã hóa khóa không đối xứng(khóa công cộng) Gói tin vắn tắt và chữ kí điện tử Chứng chỉ 5­Mã hóa khóa đối xứng( secret key)        Khoá mật mã đối xứng sử dụng một chìa khóa duy nhất cho cả hai mã  hóa và giải mã dữ  liệu.Như thể hiện trong hình bên dưới các gói tin “plain  text” đơn giản là thông qua các thuật toán mã hóa “ciphertext”, chúng không  thể   đọc,   và   do   đó   an   toàn.   Kết   quả   là   thông   tin   an   toàn   đến   người   nhận.Những người nhận giải mã thông điệp trở  lại “plaintext” bằng cách  sử dụng cùng một khóa. 4
  5.        Thuật toán mã hóa đối xứng có hai loại: mã hóa khối và mã hóa luồng.   Mã hóa khối theo truyền thống phổ biến nhất. Chúng hoạt động bằng cách  chia dữ  liệu thành các khối có kích thước cố  định, và sau đó mã hóa từng   khối riêng. Phần dữ  liệu còn lại độ  dài của “plaintext” là nhiều khối mật  mã cùng kích thước.Ngược lại, thuật toán mã hóa luồng được mã hóa bằng  bộ phát các số ngẫu nhiên. Họ sử dụng một hạt giống bắt đầu từ một chìa   khóa để  sản xuất một dòng các bit ngẫu nhiên được gọi là keystream này.  Để  mã hóa dữ liệu, một trong những có các chữ  thô và đơn giản XORs nó   với keystream này.            Bảo mật của mã hóa khóa đối xứng phụ  thuộc vào kích thước của  khóa. Khóa càng lớn, càng có nhiều khó khăn cho kẻ  đột nhập để  phá vỡ  mật mã. Tuy nhiên, khóa dài còn mất nhiều thời gian để  cho người nhận  giải mã, và có thể dẫn đến sự xuống cấp hiệu suất. 6­Mã   hóa   không   đối   xứng(Asymmetric   key   (public   key)  encryption) 5
  6.       Trong mã hóa không đối xứng,một cặp khóa bao gồm 1 “public key” và  1 “private key” để  mã hóa và giải mã dữ  liệu.  Các “public key” công khai,  nhưng không thể được sử dụng để giải mã. Chỉ có “private key” có thể giải  mã dữ liệu. Ngoài ra, “private key” có thể được dùng để mã hóa dữ liệu.         Một vấn đề  lớn với mật mã khóa riêng là làm thế  nào hai máy quyết  định về một khóa riêng an toàn. Đối với các trang web thương mại điện tử  như  amazon.com, bạn không thể  gán khóa riêng để  mỗi khách hàng có thể  trước. Mật mã hóa khóa công khai giải quyết vấn đề  này.Một khách hang  gửi dữ liệu được mã hóa đến server sử dụng khóa công khai để mã hóa.Vì  vậy, bất kỳ khách hàng có thể giao tiếp an toàn với các máy server.         Giải mã khóa bí mật là nhanh hơn nhiều để  thực hiện trên một máy  tính hơn so với giải mã khóa công khai.Trong thực tế  chúng được sử  dụng  với nhau,do đó một khóa công khai được sử  dụng để  mã hóa một khóa bí   mật được tạo ngẫu nhiên,và khóa bí mật được sử  dụng để  mã hóa thông  điệp thực tế.Đây được gọi là mã hóa “hybrid”, và được sử  dụng bởi các  giao thức SSL. 7­Bảng tóm tắt(Digests) 6
  7.       Bảng tóm tắt sử dụng để đảm bảo rằng một gói tin là hợp lệ và không   bị  sửa đổi trong quá trình truyền.Một bảng tóm tắt ngắn,thường khoảng  128 bit.Bản tóm tắt được tạo ra bằng các áp dụng một hàm băm(hash) trên   gói tin gốc.Rất khó để có thể tìm ra 2 gói tin có bảng tóm tắt giống nhau.       Cả hai gói tin và bảng tóm tắt được mã hóa và gửi đến người nhận.Sau   khi giải mã ,người nhận kiểm tra bảng tóm tắt của gói tin và so sánh với   bảng tóm tắt nhận được để  đảm bảo toàn vẹn thông điệp.  Nếu kẻ  xâm  nhập một sửa đổi trong quá trình truyền dữ  liệu đã được mã hóa, có khả  năng là các dữ liệu giải mật mã sẽ không có một bảng tóm tắt hợp lệ. 8­Chứng chỉ( Certificates)        Một chứng chỉ là một tập tin được sử dụng để xác định sự an toàn.Một  chứng chỉ thì bao gồm các thông tin: Tên máy tính Tổ chức / công ty Vị trí của máy (thành phố, tiểu bang và quốc gia) Khung thời gian giấy chứng nhận là hợp lệ Khóa công khai / khóa riêng để liên lạc an toàn Giấy chứng nhận quyền tên Giấy chứng nhận quyền chữ ký Các khoá công khai cho phép máy này giao tiếp một cách an toàn với các   máy khác. Các công ty và địa điểm cung cấp thông tin về máy. Đây là minh họa giai đoạn Authentication của 1 phiên SSL 7
  8. 9­ Lỗ hổng bảo mật của SSL:      SSL (Secure Sockets Layer) là giao thức dùng để đảm bảo an toàn cho  thông tin liên lạc trên Internet. Các nhà nghiên cứu đã tiết lộ một số kiểu  tấn công có thể được dùng để làm thương tổn việc trao đổi thông tin an  toàn giữa website và trình duyệt (tấn công có thể cho phép tin tặc đánh cắp  mật khẩu, chiếm đoạt 1 phiên giao dịch ngân hàng trực tuyến hay thậm chí  là đưa ra một bản cập nhật trình duyệt Firefox có chứa mã độc). Vấn đề  nằm trong cách nhiều trình duyệt thực thi SSL và trong hệ thống hạ tầng  khóa công khai X.509 (dùng để quản lý các chứng thức số được SSL sử  dụng để quyết định xem website có đáng tin cậy hay không).        Nhà nghiên cứu bảo mật có nickname là Moxie Marlinspike giới thiệu  kiểu tấn công “null­termination certificate” làm gián đoạn phiên duyệt SSL  giữa client và server (trong kiểu tấn công này, nếu viết  “www.paypal.com\0.thoughtcrime.org” sẽ được hiểu thành  “www.paypal.com”). Loại tấn công kiểu “man­in­the­middle” này không thể  phát hiện được, nếu lan rộng sẽ ảnh hưởng tới Internet Explorer, Firefox  3.0, phần mềm mạng riêng ảo VPN (virtual private network), các trình e­ mail client và IM (instant messaging). Để bịt lỗ hổng này thì cần cập nhật,  sửa chữa cho hệ thống X.509. 8
  9.        Tổng quan thì lỗ hổng này nằm ở sự thiếu "ăn rơ" giữa TLS/SSL và các  protocol trên nó như HTTP hay SMTP. Khai thác lỗ hổng này thì kẻ tấn  công có thể chèn thêm một đoạn plaintext bất kỳ vào TLS/SSL  encrypted stream giữa client và server mà cả client và server đều không  thể phát hiện được.        Giả định:  Ngân hàng A có cung cấp dịch vụ Internet Banking ở địa chỉ  https://www.ebank.com. Máy chủ của của họ chạy phần mềm có lỗ  hổng mà chúng ta đang bàn ở đây. Chúng ta gọi máy chủ này là server. * Để tăng cường an ninh, ngân hàng A yêu cầu khi khách hàng (gọi là  client) sử dụng các tính năng có liên quan đến giao dịch tài chính nằm  trong khu vực https://www.ebank.com/account/, thì (browser của) họ  phải có cài đặt client certificate cho ngân hàng A cung cấp. Lưu ý là  nhiều ngân hàng ở VN thực hiện cái này lắm nha. * Ngoài ra ngân hàng A còn hỗ trợ khách hàng truy cập bằng (Safari  trên) iPhone, lúc đó khách hàng sẽ được chuyển đến  https://www.ebank.com/iphone/. Do iPhone có processor yếu, nên ngân  hàng A cấu hình máy chủ web của họ để sử dụng một bộ ciphersuite  yếu hơn bộ ciphersuite mà họ sử dụng cho các khách hàng thông  thường. Có thể lợi dụng tấn công các khách hàng của ngân hàng A theo 3 hướng tấn  công mà các tác giả nêu ra. Àh lưu ý là đây là loại tấn công MITM, nghĩa là  attacker phải có quyền theo dõi, điều chỉnh dữ liệu truyền qua lại giữa  client và server. Attacker có thể làm việc này thông qua các tấn công vào các  giao thức ARP hay DNS. A­Hướng tấn công số 1 : * Bước 1: client truy cập vào https://www.ebank.com. Lúc này client sẽ kết  nối đến attacker, và gửi CLIENT_HELLO để bắt đầu giao thức TLS/SSL.  Attacker sẽ tạm dừng cái kết nối này và lưu msg CLIENT_HELLO lại để  dùng trong bước 3. * Bước 2: attacker mở kết nối đến server thật. Hai bên sẽ bắt tay theo giao  thức TLS/SSL để tạo thành một session. Sau khi hoàn tất bắt tay, attacker  gửi một HTTP request, đại loại như: 9
  10. POST /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n * Bước 3: server thấy có một request đến khu vực /account/ nên nó tạm thời  dừng xử lý request này lại và như đã nói ở trên, nó yêu cầu attacker phải  đưa client certificate cho nó xem. Cái hay ở đây, mặc dầu attacker không có  (private key của) certificate của client, nhưng hắn vẫn có thể *proxy* cái  certificate đó từ client lên server, mà không bị bên nào phát hiện cả. Server bắt đầu quá trình xác thực bằng việc gửi một msg  HELLO_REQUEST ngược lại cho attacker. Attacker nhận được msg này thì  hắn gửi CLIENT_HELLO mà hắn đã lưu ở bước 1 ngược lại cho server.  Rồi cứ thế, attacker đứng giữa, chuyển msg qua lại giữa client và server cho  đến khi quá trình xác thực bằng client certificate kết thúc thành công. Lưu ý là có 2 loại msg mà attacker sẽ gửi. Loại thứ nhất  là những msg mà  hắn phải giải mã/mã hóa trước khi gửi đi. Ví dụ như hắn nhận "Certificate"  từ phía client thì hắn sẽ mã hóa cái msg này lại, rồi mới gửi cho server.  Loại thứ hai là những msg mà hắn không đọc được (vì không có key), hắn  chỉ làm mỗi việc là nhận từ client thì gửi qua server và ngược lại. * Bước 4: quá trình xác thực client certificate đã kết thúc thành công, server  tiếp tục xử lý cái request của attacker ở trên, và trả kết quả lại cho attacker  (lưu ý là attacker sẽ không đọc được kết quả này). Điểm yếu là ở đây. Như chúng ta thấy, khi attacker gửi request ở bước 3,  lúc đó hắn chưa được xác thực. Nói cách khác, lúc này request của hắn là  unauthenticated request. Việc xác thực diễn ra sau đó, và sau khi xác thực  rồi thì server lại quay lại xử lý tiếp cái unauthenticated request của attacker. Lưu ý, ở bước này, để tránh bị tình nghi, attacker có thể tiếp tục trả kết  quả về cho client để đóng kết nối lại một cách êm đẹp.  B­Hướng tấn công số 2 : tất cả 3 hướng tấn công này đều hướng đến chôm credential của  client để gửi các authenticated request đến server. Credential ở đây có  thể là certificate (như ở hướng số 1) hay cookie/session (như ở hướng  số 2 và số 3). Nếu chỉ áp dụng cho HTTPS, nhìn ở một góc độ nào đó, các  hướng tấn công này rất giống với tấn công CSRF(Cross Site Request  10
  11. Forgery). Nên nếu ứng dụng của bạn đã có các phương thức phòng chống  CSRF  rồi hay nếu ứng dụng của bạn không chấp nhận thay đổi state bằng  GET, thì tạm thời cũng không phải có gì lo lắng. Đối với hướng số 1, lợi dụng client certificate để gửi một authenticated  request. Ở trường hợp các server không xác thực bằng certificate sẽ sử  dụng hướng tấn cống số 2. Hướng tấn công này cũng có 4 bước: * Bước số 1: tương tự như hướng tấn công số 1. * Bước 2: attacker mở kết nối đến server thật. Hai bên sẽ bắt tay theo giao  thức TLS/SSL để tạo thành một session. Sau khi hoàn tất bắt tay, attacker gửi một HTTP request, đại loại như: GET /iphone/login HTTP/1.1\r\n Host: ebank.com\r\n Connection: keep­alive\r\n \r\n GET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n Host: ebank.com\r\n Connection: close\r\n X­ignore­this: * Bước số 3: server thấy có request đến /iphone/ nên nó tạm thời dừng xử  lý request này lại và, như đã nói ở phần giả định, server sẽ bắt đầu quá  trình renegotiate lại để chọn một bộ ciphersuite yếu hơn. Vấn đề ở đây là  server sẽ buffer lại toàn bộ nhóm unauthenticated request này, khi mà  renegotiate xong thì lại quay lại xử lý hết tất cả. Trong quá trình renogotiation, vai trò của attacker cũng tương tự như ở bước  số 3 của hướng tấn công số 1, nghĩa là hắn cũng chỉ *proxy* msg qua lại  giữa client và server, cho đến khi quá trình renegotiate kết thúc thành công. * Bước số 4: lúc này, client thấy đã handshake xong rồi, nên bản thân nó sẽ  gửi tiếp cái HTTP request của nó ở dạng: GET /index HTTP/1.1\r\n 11
  12. Cookie: AuthMe=Now\r\n \r\n Chuyện bất ngờ diễn ra ở đây. Server nó sẽ gom nhóm unauthenticated  request ở bước 2 (do attacker gửi) và cái authenticated request này (do client  gửi) rồi xử lý chung một lần. Nguyên nhân server xử lý như thế là do cái cờ  keep­alive ở request đầu tiên. Thành ra lúc này nhóm request trở thành như  sau (màu cam là attacker gửi, màu xanh là client gửi): GET /iphone/login HTTP/1.1\r\n Host: ebank.com\r\n Connection: keep­alive\r\n \r\n GET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n Host: ebank.com\r\n Connection: close\r\n X­ignore­this:GET /index HTTP/1.1\r\n Cookie: AuthMe=Now\r\n \r\n Ở đây cái header X­ignore­this đã vô hiệu hóa cái request GET /index  HTTP/1.1 của client, đồng thời chôm luôn cookie của client để gắn vào cái  unauthenticated request GET /account/transfer? amount=1000&receiver=attacker. Rất hay! C­ Hướng tấn công số 3 : Đây là hướng tấn công mạnh nhất, không cần server phải có cấu hình đặc  biệt gì để thực hiện. Sự khác biệt cơ bản giữa tấn công này với hai hướng  tấn công vừa rồi là trong trường hợp này, client bắt đầu quy trình  renegotiation. Ý tưởng thực hiện tấn công rất giống với hướng 2, chỉ khác nhau ở bước  số 2, attacker sẽ không gửi GET /iphone/login nữa mà gửi trực tiếp luôn  request của hắn, kèm theo một cái "X­ignore­this" header. Ngay sau khi gửi cái request đó, attacker sẽ forward cái CLIENT_HELLO  thu được ở bước 1 sang cho phía server để bắt đầu quy trình renegotiation.  Khi đã renegotiate xong, client sẽ gửi request ban đầu của mình đến server,  12
  13. lúc này toàn bộ request sẽ trông như sau (phần màu cam của attacker gửi,  phần màu xanh của client gửi): GET /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n Host: ebank.com\r\n Connection: close\r\n X­ignore­this: GET /index HTTP/1.1\r\n Cookie: AuthMe=Now\r\n \r\n Tương tự ở trên, X­ignore­this đã vô hiệu hóa request của client và chôm  cookie để biến request của attacker thành authenticated. Không cần keep­ alive, không cần server phải có cấu hình đặc biệt gì cả! http://en.wikipedia.org/wiki/Transport_Layer_Security http://www.instantssl.com/ssl­certificate­products/what_is_ssl.html http://www.safescrypt.com/faq/faqsslbasics.html#Top http://www.visolve.com/security/ssl_intro.php http://www.vnsecurity.net/t/tls/  “SSL and TLS Essentials” – Securing the Web –Stephen Thomas 13
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

 

Đồng bộ tài khoản
5=>2