Trước hết, hãy cố gắng hiểu cách xác thực SSL (HTTPS) và HTTP.
Các phương thức xác thực HTTP thông thường (Digest, Basic và bất kỳ biểu mẫu + sơ đồ xác thực dựa trên cookie nào bạn có thể triển khai trên HTTP) đều không an toàn bởi vì chúng gửi thông tin xác thực ít nhiều bằng văn bản rõ ràng. Cho dù dữ liệu nằm trong các trường POST hoặc tiêu đề và liệu mã hóa base64 có được áp dụng hay không, không có vấn đề gì về vấn đề này, mật khẩu sẽ hiển thị rõ ràng cho bất kỳ ai có quyền truy cập vào lưu lượng mạng. Điều này có nghĩa là xác thực HTTP trên một kênh không đáng tin cậy là vô ích: tất cả những gì kẻ tấn công đọc được mật khẩu của bạn chỉ là một chút đánh hơi mạng.
SSL thực hiện một kênh liên lạc an toàn trên một kênh không an toàn vốn có. Điều này hoạt động, đại khái, như sau:
- Máy chủ gửi chứng chỉ đã ký
- Khách hàng xác nhận chứng chỉ dựa vào danh sách các khóa ký kết đã biết; Chữ ký chứng chỉ có thể được xâu chuỗi, để mỗi nút nói "nếu chữ ký ký tên tôi là tốt, thì tôi cũng vậy", nhưng cuối cùng, chuỗi cần giải quyết với một trong số ít các cơ quan đáng tin cậy được cấu hình sẵn trên máy khách.
- Khách hàng sử dụng khóa mã hóa công khai của máy chủ để gửi bí mật chung
- Máy chủ giải mã bí mật được chia sẻ bằng khóa riêng (vì chỉ máy chủ hợp pháp mới có khóa riêng, các máy chủ khác sẽ không thể giải mã được bí mật được chia sẻ)
- Khách hàng gửi dữ liệu yêu cầu thực tế, được mã hóa bằng bí mật được chia sẻ
- Máy chủ giải mã dữ liệu yêu cầu, sau đó gửi phản hồi được mã hóa
- Khách hàng giải mã phản hồi và trình bày nó cho người dùng.
Lưu ý một vài điểm quan trọng ở đây:
- Chuỗi chứng chỉ cho phép khách hàng đảm bảo rằng máy chủ mà họ đang nói chuyện là máy chủ thực sự chứ không phải ai đó chặn yêu cầu của họ. Đây là lý do tại sao bạn nên mua chứng chỉ SSL thực và tại sao trình duyệt đưa ra những cảnh báo đáng sợ cho bạn khi bạn truy cập trang web sử dụng chứng chỉ không hợp lệ, hết hạn hoặc không chính xác: tất cả mã hóa trên thế giới không giúp ích gì nếu bạn nói chuyện với người sai.
- Mã hóa công khai / riêng được sử dụng để trao đổi bí mật đảm bảo rằng giao tiếp thành công sẽ chỉ hoạt động giữa cặp máy khách và máy chủ cụ thể này: các gói mạng được đánh hơi sẽ được mã hóa và chúng sẽ yêu cầu khóa riêng của máy chủ để lấy dữ liệu.
- Mã hóa đối xứng được sử dụng cho phần lớn yêu cầu, bởi vì nó có chi phí hoạt động thấp hơn nhiều so với mã hóa khóa riêng / công khai. Khóa (bí mật chung) được trao đổi bằng cách sử dụng mã hóa khóa riêng / công khai, bởi vì đó là cách duy nhất để làm điều đó một cách an toàn (ngoại trừ vận chuyển nó qua một kênh riêng, chẳng hạn như dịch vụ chuyển phát nhanh).
Vì vậy, rõ ràng, có một số chi phí liên quan, nhưng nó không tệ như bạn nghĩ - chủ yếu ở quy mô mà "ném thêm phần cứng vào nó" là phản ứng thích hợp, trừ khi bạn đang chuẩn bị cho lưu lượng truy cập cực lớn ( nghĩ rằng Google hoặc Facebook). Trong các trường hợp thông thường, nghĩa là, việc sử dụng ứng dụng web thông thường, chi phí SSL là không đáng kể và do đó, ngay khi bạn có bất kỳ dữ liệu bí mật nào, tốt nhất là chỉ chạy mọi thứ qua SSL, bao gồm cả tài nguyên. SSL cũng là cách khả thi duy nhất để đảm bảo lưu lượng HTTP; các phương pháp khác đơn giản là không được chuẩn hóa và do đó không được hỗ trợ rộng rãi và bạn hoàn toàn không muốn tự mình thực hiện những điều này, vì thành thật mà nói, thật quá dễ để hiểu sai.
TL; DR: Có, SSL + Xác thực cơ bản là một ý tưởng hay, vâng, bạn cần một máy chủ an toàn (và chứng chỉ hợp lệ ), vâng, nó sẽ làm mọi thứ chậm lại một chút, nhưng không, đây không phải là điều đáng lo ngại hiện nay.