Socket đã trở thành API CTĐ phổ biến nhất trong cộng đồng Internet. Do việc sử dụng rộng rãi các ứng dụng Windows mà nhóm chuẩn WinSock, bao gồm hơn 30 hãng công nghiệp (kể cả MicroSoft) đã phát triển một socket Windows chuẩn (WinSock). WinSock bắt nguồn từ socket Berkeley. Nó gồm một tập công phu các API và đ−ợc mở rộng nhằm cung cấp tính trong suốt giao vận hoàn hảo khi sử dụng giao diện cung cấp dịch vụ (SPI: Service Provider Interface) trừu t−ợng làm dễ dàng t−ơng thích plug-in cho hầu hết các giao thức giao vận. Phiên bản gần nhất cũng chứa tầng socket an toàn (SSL: Secure Socket Layer).
Đòi hỏi an toàn TT trên Internet đã thúc đẩy IETF (Internet Engineering Task Force) phát triển SSL. Mục tiêu SSL là cung cấp:
- Bảo mật trong TT socket khi dùng mã đối xứng để mã hoá dữ liệu - Toàn vẹn dữ liệu trong socket khi kiểm tra tính toàn vẹn TĐ
- Xác thực phục vụ và khách khi dùng mã hóa khóa công khai bất đối xứng. Điểm chủ yếu của SSL chứa trong hai mức giao thức: một giao thức Handshake và một giao thức Record Layer. Giao thức Handshake t−ơng ứng thiết lập các khóa ghi (khóa phiên TT để bí mật dữ liệu) và MAC (Message Authentication Check để toàn vẹn dữ liệu) bí mật và xác nhận tính xác thực của phục vụ và khách. Giao thức Record Layer thích hợp để phân đoạn, nén/giãn nén và mã hóa/giải mã các bản ghi của TĐ. Kết quả cuối cùng của giao thức Handshake là một cấu trúc dữ liệu chia xẻ (đ−ợc gọi là mastersecret) chỉ khách và phục vụ biết đ−ợc, mà có thể đ−ợc biến đổi thành write key
và một MAC secret để TT an toàn bằng Record Layer.
Hình 4.6. trình bày một kịch bản đơn giản của giao thức Handshake SSL. Khách muốn liên lạc với phục vụ bằng cách gửi TĐ ClientHello tới phục vụ đó. Thành phần chính của TĐ chứa một số ngẫu nhiên (randomC) và một tập thuật toán mật mã (CipherSuites). Số ngẫu nhiên đ−ợc dùng để tính toán mastersecret quyết định. CipherSuites là một danh sách lựa chọn mã hóa đ−ợc phục vụ đàm phán và chọn. Phục vụ trả lại cho khách một TĐ phục vụHello chứa một số ngẫu nhiên randomS, một thuật toán mã hóa CipherSuite đ−ợc chọn và một định danh phiên cho kết nối.
Tại thời điểm này, phục vụ có thể xác nhận định danh của nó bằng việc gửi một giấy chứng nhận tới khách. Giấy chứng nhận đ−ợc cho bằng giấy xác thực (CA) nhóm ba. Giấy chứng nhận đ−ợc QT cấp giấy ký khi dùng khóa bí mật của nó và nh− vậy không thể dễ giả mạo. SSL dùng xác nhận X.509. Phục vụ có thể yêu cầu giấy chứng nhận của khách. Mỗi một chứng nhận mang thành phần khóa công khai trong cặp gồm khóa công khai và khóa bí mật của đối t−ợng đ−ợc ghi nhận (khách hoặc phục vụ). Khách cần khóa công khai của phục vụ để biến đổi thông tin bí mật tới phục vụ. Mã hóa khóa công khai đ−ợc trình bày trong ch−ơng sau. Ph−ơng pháp cặp khóa kép (công khai và bí mật) đ−ợc coi là một thuật toán mã hóa. Với nó, một TĐ đ−ợc mã hóa bởi một khóa công khai có thể đ−ợc giải mã bằng khóa bí mật t−ơng ứng và ng−ợc lại. Khóa công
khai đ−ợc ghi nhận bằng thông tin công khai còn khóa bí mật chỉ có các đối t−ợng biết. Để đơn giản hóa trong trình bày giao thức Handshake SSL ở hình 4.6 đã bỏ qua việc xác nhận tính hợp lệ của các giấy chứng nhận.
Không cần giấy chứng nhận, một phục vụ nặc danh có thể gửi khoá công khai của nó trong TĐ phục vụKeyExchange tới Khách. Khóa công khai này không cần phải là khóa
đã đ−ợc ghi nhận. Phục vụ sinh tạm thời khóa công khai để sử dụng theo từng lần yêu cầu của khách. Khách đáp lại bằng một TĐ ClientKeyExchange mang một pre- mastersecret mã hóa theo khóa công khai tạm thời của phục vụ. Chỉ có phục vụ với khóa bí mật t−ơng ứng mới giải mã đ−ợc pre-mastersecret. Lúc đó, cả khách và phục vụ chia xẻ pre-mastersecret và hai số ngẫu nhiên. Cả hai QT độc lập áp dụng hàm băm một chiều tới thông tin chia xẻ để chuyển pre-mastersecret quyết định chứa khóa ghi (write key) và MAC bí mật. Các khóa và MAC bí mật này đ−ợc dùng để liên kết với bộ mật mã vừa đ−ợc đàm phán. Chúng đ−ợc ChangeCipherSpec tạo hiệu quả nhằm thay thế bộ mật mã cũ bằng một bộ mới. Các TĐ finished chấm dứt việc bắt tay. Chúng cũng đ−ợc dùng để xác minh việc trao đổi khóa và xác thực có thành công hay không. Việc kiểm tra thông qua xác nhận TĐ finished chứa kết quả băm của mastersecret đ−ợc móc nối với mọi TĐ bắt tay.
TT socket an toàn đ−ợc bắt đầu sau khi TĐ finished đã đ−ợc trao đổi và kiểm tra. Mọi TĐ socket tiếp sau đ−ợc mã hóa theo thuật toán mã hóa và khóa ghi bí mật đã đ−ợc thiết lập cho đến khi phiên đ−ợc th−ơng l−ợng lại. Mọi TĐ chứa một bộ kiểm tra xác thực TĐ là kết quả băm TĐ với MAC bí mật. Không có MAC bí mật, sản xuất MAC cho TĐ tạm thời trở nên bất hợp lý. TĐ socket đ−ợc xử lý bởi Record Layer trở thành bí mật và bền vững. Khái niệm giao thức socket an toàn vẫn đang đ−ợc tiếp tục tiến hóa và cải tiến.