Các bước được đề cập trong bài viết này
- Tạo một cặp khoá công khai/riêng tư RSA 2048 bit.
- Tạo yêu cầu ký chứng chỉ (CSR) sẽ nhúng khóa công khai của bạn.
- Hãy chia sẻ CSR với tổ chức phát hành chứng chỉ (CA) để nhận chứng chỉ cuối cùng hoặc chuỗi chứng chỉ.
- Cài đặt chứng chỉ cuối cùng của bạn ở nơi không thể truy cập trên web, chẳng hạn như
/etc/ssl(Linux và Unix) hoặc bất cứ nơi nào IIS yêu cầu (Windows).
Đang tạo khoá và yêu cầu ký chứng chỉ
Phần này sử dụng chương trình dòng lệnh OpenGL, có sẵn với hầu hết hệ thống Linux, BSD và Mac OS X để tạo khoá riêng tư/công khai và CSR.
Tạo cặp khoá công khai/riêng tư
Hãy bắt đầu bằng cách tạo một cặp khoá RSA 2.048 bit. Khoá nhỏ hơn, chẳng hạn như 1.024 bit, sẽ không đủ khả năng chống lại các cuộc tấn công suy đoán brute force. Khoá lớn hơn, chẳng hạn như 4.096 bit, là mức quá mức cần thiết. Theo thời gian, kích thước khoá sẽ tăng lên khi việc xử lý trên máy tính ngày càng rẻ hơn. 2.048 hiện đang là điểm hấp dẫn.
Lệnh để tạo cặp khoá RSA là:
openssl genrsa -out www.example.com.key 2048
Kết quả như sau:
Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)
Tạo yêu cầu ký chứng chỉ
Ở bước này, bạn nhúng khoá công khai và thông tin về tổ chức và trang web của bạn vào một yêu cầu ký chứng chỉ hoặc CSR. Lệnh openssl sẽ yêu cầu bạn cung cấp siêu dữ liệu bắt buộc.
Chạy lệnh sau:
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
Cho ra kết quả như sau:
You are about to be asked to enter information that will be incorporated
into your certificate request
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Để đảm bảo tính hợp lệ của CSR, hãy chạy lệnh sau:
openssl req -text -in www.example.com.csr -noout
Và phản hồi sẽ có dạng như sau:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
...
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
...
Gửi CSR của bạn đến tổ chức phát hành chứng chỉ
Các tổ chức phát hành chứng chỉ (CA) khác nhau có những phương thức khác nhau để gửi CSR của bạn. Các phương thức có thể bao gồm sử dụng một biểu mẫu trên trang web, gửi Đại diện dịch vụ khách hàng qua email hoặc cách thức khác. Một số CA (hoặc đại lý của họ) thậm chí có thể tự động hoá một số hoặc toàn bộ quy trình (trong một số trường hợp, bao gồm cặp khoá và tạo CSR).
Gửi CSR đến CA và làm theo hướng dẫn của họ để nhận chứng chỉ hoặc chuỗi chứng chỉ cuối cùng.
Mỗi CA sẽ tính số tiền khác nhau cho dịch vụ bảo đảm khoá công khai của bạn.
Ngoài ra, bạn cũng có thể liên kết khoá với nhiều tên DNS, trong đó có một số tên riêng biệt (ví dụ: tất cả example.com, www.example.com, example.net và www.example.net) hoặc tên "ký tự đại diện" như *.example.com.
Ví dụ: một CA hiện cung cấp các mức giá sau:
- Tiêu chuẩn: 16 USD/năm, hợp lệ cho example.com và www.example.com.
- Ký tự đại diện: $150/năm, hợp lệ cho example.com và *.example.com.
Với mức giá này, chứng chỉ ký tự đại diện tiết kiệm chi phí khi bạn có nhiều hơn 9 miền con; nếu không, bạn chỉ cần mua một hoặc nhiều chứng chỉ có một tên. (Chẳng hạn, nếu có nhiều hơn 5 miền con, thì có thể bạn sẽ thấy chứng chỉ ký tự đại diện thuận tiện hơn khi bật HTTPS trên máy chủ của mình.)
Sao chép chứng chỉ vào tất cả máy chủ giao diện người dùng của bạn ở một nơi không thể truy cập trên web, chẳng hạn như /etc/ssl (Linux và Unix) hoặc bất cứ nơi nào IIS (Windows) yêu cầu.
Bật HTTPS trên máy chủ của bạn
Việc bật HTTPS trên máy chủ là một bước quan trọng trong việc cung cấp tính bảo mật cho các trang web của bạn.
- Sử dụng công cụ Cấu hình máy chủ của Mozilla để thiết lập máy chủ của bạn nhằm hỗ trợ HTTPS.
- Hãy thường xuyên kiểm tra trang web của bạn bằng công cụ Kiểm tra máy chủ SSL tiện dụng của Qualys và đảm bảo bạn đạt được điểm A hoặc A+ ít nhất.
Tại thời điểm này, bạn phải đưa ra quyết định vận hành quan trọng. Chọn một trong các lựa chọn sau:
- Dành riêng một địa chỉ IP riêng biệt cho mỗi tên máy chủ mà máy chủ web của bạn phân phát nội dung.
- Sử dụng dịch vụ lưu trữ ảo theo tên.
Nếu đang sử dụng các địa chỉ IP riêng biệt cho mỗi tên máy chủ, bạn có thể dễ dàng hỗ trợ cả HTTP và HTTPS cho tất cả ứng dụng.
Tuy nhiên, hầu hết các nhà điều hành trang web đều sử dụng tính năng lưu trữ ảo dựa trên tên để bảo toàn địa chỉ IP và vì nhìn chung thì việc này thuận tiện hơn. Vấn đề với IE trên Windows XP và Android phiên bản cũ hơn 2.3 là các API này không hiểu Chỉ báo tên máy chủ (SNI), một điều rất quan trọng đối với dịch vụ lưu trữ ảo dựa trên tên HTTPS.
Hy vọng rằng một ngày nào đó, các ứng dụng không hỗ trợ DEX sẽ được thay thế bằng phần mềm hiện đại. Hãy theo dõi chuỗi tác nhân người dùng trong nhật ký yêu cầu để biết khi nào đã có đủ số người dùng chuyển sang phần mềm hiện đại. (Bạn có thể quyết định ngưỡng của mình là bao nhiêu; có thể dưới 5% hoặc ít hơn 1%.)
Nếu bạn chưa có sẵn dịch vụ HTTPS trên máy chủ của mình, hãy bật dịch vụ này ngay bây giờ (mà không cần chuyển hướng HTTP sang HTTPS; hãy xem bên dưới). Định cấu hình máy chủ web của bạn để sử dụng các chứng chỉ mà bạn đã mua và cài đặt. Bạn có thể thấy trình tạo cấu hình tiện dụng của Mozilla hữu ích.
Nếu bạn có nhiều tên máy chủ hoặc miền con, thì mỗi tên máy chủ hoặc miền con đó cần sử dụng đúng chứng chỉ.
Bây giờ, trong suốt thời gian tồn tại của trang web, hãy kiểm tra cấu hình HTTPS bằng công cụ Kiểm tra máy chủ SSL tiện dụng của Qualys. Trang web của bạn phải đạt điểm A hoặc A+; hãy coi mọi vấn đề gây ra điểm thấp hơn là lỗi. (A của hôm nay sẽ là B của ngày mai, vì các cuộc tấn công vào thuật toán và giao thức luôn được cải tiến!)
Đặt URL trong trang web tương đối
Giờ đây, khi mà bạn đang phân phát trang web của mình trên cả HTTP và HTTPS, mọi thứ đều cần hoạt động suôn sẻ nhất có thể, bất kể giao thức là gì. Một yếu tố quan trọng là sử dụng URL tương đối cho các đường liên kết nội bộ.
Đảm bảo URL trong trang web và URL bên ngoài không phụ thuộc vào giao thức; nghĩa là, hãy đảm bảo bạn sử dụng đường dẫn tương đối hoặc loại bỏ giao thức như //example.com/something.js.
Vấn đề sẽ phát sinh khi bạn phân phát một trang qua HTTPS có chứa tài nguyên HTTP, hay còn gọi là nội dung hỗn hợp. Các trình duyệt cảnh báo người dùng rằng toàn bộ sức mạnh của HTTPS đã bị mất. Trên thực tế, trong trường hợp nội dung hỗn hợp đang hoạt động (tập lệnh, trình bổ trợ, CSS, iframe), các trình duyệt thường không tải hoặc thực thi nội dung nào, dẫn đến một trang bị hỏng. Và hãy nhớ rằng bạn hoàn toàn có thể đưa tài nguyên HTTPS vào trang HTTP.
Ngoài ra, khi bạn liên kết đến trang khác trên trang web của mình, người dùng có thể bị hạ cấp từ HTTPS xuống HTTP.
Những sự cố này xảy ra khi các trang của bạn bao gồm các URL nội bộ đủ điều kiện và sử dụng lược đồ http://.
<h1>Welcome To Example.com</h1> <script src="http://example.com/jquery.js"></script> <link rel="stylesheet" href="http://assets.example.com/style.css"/> <img src="http://img.example.com/logo.png"/>; <p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>Tránh sử dụng các URL nội bộ đủ điều kiện.
Nói cách khác, hãy tạo URL nội trang càng tương đối càng tốt: giao thức tương đối (thiếu giao thức, bắt đầu bằng //example.com) hoặc
tương đối với máy chủ (bắt đầu bằng đường dẫn, chẳng hạn như /jquery.js).
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24/">new post on cats!</a></p>Dùng URL nội bộ tương đối.
<h1>Welcome To Example.com</h1> <script src="//example.com/jquery.js"></script> <link rel="stylesheet" href="//assets.example.com/style.css"/> <img src="//img.example.com/logo.png"/>; <p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>Hoặc sử dụng URL nội bộ tương đối liên quan đến giao thức.
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24/">new post on cats!</a></p> <p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>Sử dụng URL loại HTTPS cho URL liên trang web (nếu có thể).
Thực hiện việc này bằng một kịch bản, chứ không phải bằng thủ công. Nếu nội dung trang web của bạn nằm trong cơ sở dữ liệu, hãy kiểm tra tập lệnh của bạn trên bản sao phát triển của cơ sở dữ liệu. Nếu nội dung trang web của bạn bao gồm các tệp đơn giản, hãy kiểm thử tập lệnh trên bản sao đang phát triển của các tệp đó. Chỉ chuyển các thay đổi lên phiên bản chính thức sau khi các thay đổi vượt qua quy trình đảm bảo chất lượng như bình thường. Bạn có thể sử dụng tập lệnh của Bram van Damme hoặc thứ gì đó tương tự để phát hiện nội dung hỗn hợp trên trang web của mình.
Khi liên kết đến các trang web khác (thay vì bao gồm tài nguyên từ các trang web đó), bạn không nên thay đổi giao thức vì bạn không có quyền kiểm soát cách hoạt động của các trang web đó.
Để di chuyển suôn sẻ hơn cho các trang web lớn, bạn nên sử dụng URL tương đối về giao thức. Nếu bạn không chắc liệu mình có thể triển khai HTTPS đầy đủ hay không, thì việc buộc trang web của bạn sử dụng HTTPS cho tất cả các tài nguyên phụ có thể bị phản hồi. Có thể có khoảng thời gian HTTPS còn mới mẻ và lạ lẫm với bạn, và trang web HTTP vẫn phải hoạt động hiệu quả như bao giờ hết. Theo thời gian, bạn sẽ hoàn tất quá trình di chuyển và khoá trong HTTPS (xem hai phần tiếp theo).
Nếu trang web của bạn phụ thuộc vào tập lệnh, hình ảnh hoặc tài nguyên khác được phân phát từ bên thứ ba, chẳng hạn như CDN hoặc jquery.com, bạn có hai lựa chọn:
- Sử dụng URL giao thức tương đối cho các tài nguyên này. Nếu bên thứ ba không phân phát HTTPS, hãy yêu cầu họ. Hầu hết các trang web đã có, bao gồm jquery.com.
- Phân phát tài nguyên từ một máy chủ mà bạn kiểm soát và máy chủ này cung cấp cả HTTP và HTTPS. Dù sao thì đây cũng thường là ý tưởng hay vì khi đó bạn sẽ kiểm soát tốt hơn giao diện, hiệu suất và tính bảo mật của trang web. Ngoài ra, bạn không cần phải tin tưởng bên thứ ba. Điều này luôn tốt.
Chuyển hướng HTTP sang HTTPS
Bạn cần đặt một đường liên kết chính tắc ở đầu trang để cho các công cụ tìm kiếm biết rằng HTTPS là cách tốt nhất để truy cập vào trang web của bạn.
Thiết lập thẻ <link rel="canonical" href="https://…"/> trong các trang của bạn. Điều này giúp các công cụ tìm kiếm xác định cách tốt nhất để truy cập vào trang web của bạn.
Bật tính năng Bảo mật truyền tải nghiêm ngặt và cookie bảo mật
Tại thời điểm này, bạn đã sẵn sàng "thúc đẩy" việc sử dụng HTTPS.
- Hãy sử dụng giao thức Bảo mật truyền tải nghiêm ngặt HTTP (HSTS) để tránh chi phí cho lệnh chuyển hướng 301.
- Luôn đặt cờ An toàn trên cookie.
Trước tiên, hãy sử dụng tính năng Bảo mật truyền tải nghiêm ngặt để thông báo cho khách hàng biết rằng họ phải luôn kết nối với máy chủ của bạn qua HTTPS, ngay cả khi theo dõi tham chiếu http://. Điều này đánh bại các cuộc tấn công như Xoá SSL, đồng thời tránh được chi phí khứ hồi của 301 redirect mà chúng tôi đã bật trong Chuyển hướng HTTP sang HTTPS.
Bật tính năng Bảo mật truyền tải nghiêm ngặt HTTP (HSTS) bằng cách đặt tiêu đề Strict-Transport-Security. Trang HSTS của OWASP có các đường liên kết đến hướng dẫn cho nhiều phần mềm máy chủ.
Hầu hết các máy chủ web đều cung cấp khả năng tương tự để thêm tiêu đề tuỳ chỉnh.
Bạn cũng cần đảm bảo rằng ứng dụng không bao giờ gửi cookie (chẳng hạn như để xác thực hoặc lựa chọn ưu tiên về trang web) qua HTTP. Ví dụ: nếu cookie xác thực của người dùng hiển thị dưới dạng văn bản thuần tuý, thì biện pháp đảm bảo bảo mật cho toàn bộ phiên hoạt động của cookie sẽ bị huỷ bỏ – ngay cả khi bạn đã làm mọi thứ khác đúng cách!
Do đó, hãy thay đổi ứng dụng web của bạn để luôn đặt cờ Bảo mật trên các cookie mà ứng dụng đặt. Trang OWASP này giải thích cách đặt cờ Bảo mật trong một số khung ứng dụng. Mỗi khung ứng dụng đều có một cách để đặt cờ.
Hầu hết máy chủ web đều cung cấp tính năng chuyển hướng đơn giản. Hãy dùng 301 (Moved Permanently) để cho công cụ tìm kiếm và trình duyệt biết rằng phiên bản HTTPS là phiên bản chính tắc, đồng thời chuyển hướng người dùng từ HTTP đến phiên bản HTTPS của trang web.
Thứ hạng tìm kiếm
Google sử dụng HTTPS làm chỉ báo chất lượng tìm kiếm tích cực. Google cũng phát hành hướng dẫn về cách di chuyển, di chuyển trang web mà vẫn duy trì thứ hạng trong kết quả tìm kiếm. Bing cũng xuất bản các nguyên tắc dành cho quản trị viên trang web.
Hiệu suất
Khi các lớp nội dung và ứng dụng được điều chỉnh tốt (xem Sách của Steve Souders để biết lời khuyên hữu ích), những vấn đề còn lại về hiệu suất TLS thường nhỏ, so với tổng chi phí của ứng dụng. Ngoài ra, bạn có thể giảm và khấu hao các chi phí đó. (Để nắm được lời khuyên hữu ích về việc tối ưu hoá TLS và nói chung, hãy xem bài viết Mạng lưới trình duyệt hiệu suất cao của Ilya Grigorik.) Xem thêm Sách dạy về OpenSSL và SSL và TLS của Ivan Ristic.
Trong một số trường hợp, TLS có thể cải thiện hiệu suất, chủ yếu là nhờ việc cung cấp HTTP/2. Chris Palmer đã nói về hiệu suất HTTPS và HTTP/2 tại Hội nghị Nhà phát triển Chrome 2014.
Tiêu đề tham chiếu
Khi người dùng truy cập vào các đường liên kết từ trang web HTTPS của bạn đến các trang web HTTP khác, tác nhân người dùng sẽ không gửi tiêu đề Giới thiệu. Nếu đây là vấn đề, có một số cách để giải quyết:
- Các trang web khác nên di chuyển sang HTTPS. Nếu trang web được giới thiệu có thể hoàn thành phần Bật HTTPS trên máy chủ của bạn của hướng dẫn này, thì bạn có thể thay đổi các đường liên kết trong trang web của mình thành đường liên kết của trang web đó từ
http://thànhhttps://, hoặc bạn có thể sử dụng đường liên kết tương đối đến giao thức. - Để giải quyết nhiều vấn đề về tiêu đề Người giới thiệu, hãy sử dụng tiêu chuẩn Chính sách liên kết giới thiệu mới.
Do các công cụ tìm kiếm đang di chuyển sang HTTPS, nên trong tương lai, có thể bạn sẽ thấy nhiều tiêu đề Tham chiếu hơn khi di chuyển sang HTTPS.
Doanh thu từ quảng cáo
Các nhà điều hành trang web kiếm tiền từ trang web của họ bằng cách hiển thị quảng cáo muốn đảm bảo rằng
việc di chuyển sang HTTPS không làm giảm số lần hiển thị quảng cáo. Tuy nhiên, do những vấn đề về bảo mật nội dung hỗn hợp, nên HTTP <iframe> không hoạt động trên trang HTTPS. Có một vấn đề phức tạp về hành động tập thể ở đây: cho đến khi nhà quảng cáo phát hành qua HTTPS, các nhà điều hành trang web không thể di chuyển sang HTTPS mà không bị mất doanh thu quảng cáo; nhưng cho đến khi các nhà điều hành trang web di chuyển sang HTTPS, nhà quảng cáo sẽ có ít động lực để phát hành HTTPS.
Nhà quảng cáo ít nhất nên cung cấp dịch vụ quảng cáo qua HTTPS (chẳng hạn như bằng cách hoàn tất phần "Bật HTTPS trên máy chủ của bạn" trên trang này). Nhiều nhà quảng cáo đã làm như vậy. Bạn nên yêu cầu các nhà quảng cáo không phân phát HTTPS ít nhất bắt đầu. Bạn có thể trì hoãn việc hoàn thành phần Tạo URL trang web tương đối cho đến khi có đủ nhà quảng cáo tương tác đúng cách.