Mercurial > hg > nginx-site

comparison xml/cn/docs/http/configuring_https_servers.xml @ 720:9934338f83af

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Updated the Chinese documentation.
author Ruslan Ermilov <ru@nginx.com>
date Thu, 11 Oct 2012 10:23:05 +0000
parents 130fad6dc1b4
children
comparison
equal deleted inserted replaced
719:6a37df6078a1 720:9934338f83af
1 <!DOCTYPE article SYSTEM "../../../../dtd/article.dtd"> 1 <!--
2 Copyright (C) Igor Sysoev
3 Copyright (C) Nginx, Inc.
4 -->
5
6 <!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
2 7
3 <article name="配置HTTPS服务器" 8 <article name="配置HTTPS服务器"
4 link="/cn/docs/http/configuring_https_servers.html" 9 link="/cn/docs/http/configuring_https_servers.html"
5 lang="cn" 10 lang="cn"
11 rev="3"
12 translator="cfsego"
6 author="Igor Sysoev" 13 author="Igor Sysoev"
7 editor="Brian Mercer"> 14 editor="Brian Mercer">
8 15
9 <section> 16 <section>
10 17
11 <para> 18 <para>
12 配置HTTPS主机，必须在server配置块中打开SSL协议，还需要指定服务器端证书和密钥文件的位置： 19 配置HTTPS主机，必须在server配置块中打开SSL协议，还需要指定服务器端证书和密钥文件的位置：
13 20
14 <programlisting> 21 <programlisting>
15 server { 22 server {
16 listen 443; 23 listen 443;
17 server_name www.nginx.com; 24 server_name www.example.com;
18 ssl on; 25 ssl <b>on</b>;
19 ssl_certificate www.nginx.com.crt; 26 ssl_certificate <b>www.example.com.crt</b>;
20 ssl_certificate_key www.nginx.com.key; 27 ssl_certificate_key <b>www.example.com.key</b>;
21 ssl_protocols SSLv3 TLSv1; 28 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
22 ssl_ciphers HIGH:!aNULL:!MD5; 29 ssl_ciphers HIGH:!aNULL:!MD5;
23 ... 30 ...
24 } 31 }
25 </programlisting> 32 </programlisting>
26 33
27 服务器证书是公开的，会被传送到所有连接到服务器的客户端。而私钥不是公开的，需要存放在访问受限的文件中，当然，nginx主进程必须有读取密钥的权限。还有一种情况，私钥和证书存放在同一个文件中： 34 服务器证书是公开的，会被传送到每一个连接到服务器的客户端。而私钥不是公开的，需要存放在访问受限的文件中，当然，nginx主进程必须有读取密钥的权限。私钥和证书可以存放在同一个文件中：
28 35
29 36 <programlisting>
30 <programlisting> 37 ssl_certificate www.example.com.cert;
31 ssl_certificate www.nginx.com.cert; 38 ssl_certificate_key www.example.com.cert;
32 ssl_certificate_key www.nginx.com.cert; 39 </programlisting>
33 </programlisting>
34
35 40
36 这种情况下，证书文件同样得设置访问限制。当然，虽然证书和密钥存放在同一个文件，只有证书会发送给客户端，密钥不会发送。 41 这种情况下，证书文件同样得设置访问限制。当然，虽然证书和密钥存放在同一个文件，只有证书会发送给客户端，密钥不会发送。
37 </para> 42 </para>
38 43
39 <para> 44 <para>
40 45 <link doc="ngx_http_ssl_module.xml" id="ssl_protocols"/>和<link doc="ngx_http_ssl_module.xml" id="ssl_ciphers"/>指令可以用来强制用户连接只能引入SSL/TLS那些强壮的协议版本和强大的加密算法。从1.0.5版本开始，nginx默认使用“<literal>ssl_protocols SSLv3 TLSv1</literal>”和“<literal>ssl_ciphers HIGH:!aNULL:!MD5</literal>”，所以只有在之前的版本，明确地配置它们才是有意义的。从1.1.13和1.0.12版本开始，nginx默认使用“<literal>ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2</literal>”。
41 <literal>ssl_protocols</literal>和<literal>ssl_ciphers</literal>指令可以用来强制用户连接只能引入SSL/TLS那些强壮的协议版本和强大的加密算法。从1.0.5版本开始，nginx默认使用<literal>ssl_protocols SSLv3 TLSv1</literal>和<literal>ssl_ciphers HIGH:!aNULL:!MD5</literal>，所以只有在之前的版本，明确地配置它们才是有意义的。
42 </para> 46 </para>
43 47
44 <para> 48 <para>
45 CBC模式的加密算法容易受到一些攻击，尤其是BEAST攻击（参见<link url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389">CVE-2011-3389</link>）。可以通过下面配置调整为优先使用RC4-SHA加密算法： 49 CBC模式的加密算法容易受到一些攻击，尤其是BEAST攻击（参见<link url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389">CVE-2011-3389</link>）。可以通过下面配置调整为优先使用RC4-SHA加密算法：
46 50
54 58
55 59
56 <section id="optimization" name="HTTPS服务器优化"> 60 <section id="optimization" name="HTTPS服务器优化">
57 61
58 <para> 62 <para>
59 SSL操作需要消耗CPU资源，所以在多处理器的系统，需要启动多个工作进程，而且数量需要不少于可用CPU的个数。最消耗CPU资源的SSL操作是SSL握手，有两种方法可以将每个客户端的握手操作数量降到最低：第一种是保持客户端长连接，在一个SSL连接发送多个请求，第二种是在并发的连接或者后续的连接中重用SSL会话参数，这样可以避免SSL握手的操作。会话缓存用于保存SSL会话，这些缓存在工作进程间共享，可以使用<literal>ssl_session_cache</literal>指令进行配置。1M缓存可以存放大约4000个会话。默认的缓存超时是5分钟，可以使用<literal>ssl_session_timeout</literal>来修改。下面是一个针对4核系统的配置优化的例子，使用10M的共享会话缓存： 63 SSL操作需要消耗CPU资源，所以在多处理器的系统，需要启动多个工作进程，而且数量需要不少于可用CPU的个数。最消耗CPU资源的SSL操作是SSL握手，有两种方法可以将每个客户端的握手操作数量降到最低：第一种是保持客户端长连接，在一个SSL连接发送多个请求，第二种是在并发的连接或者后续的连接中重用SSL会话参数，这样可以避免SSL握手的操作。会话缓存用于保存SSL会话，这些缓存在工作进程间共享，可以使用<link doc="ngx_http_ssl_module.xml" id="ssl_session_cache"/>指令进行配置。1M缓存可以存放大约4000个会话。默认的缓存超时是5分钟，可以使用<link doc="ngx_http_ssl_module.xml" id="ssl_session_timeout"/>加大它。下面是一个针对4核系统的配置优化的例子，使用10M的共享会话缓存：
60 64
61 <programlisting> 65 <programlisting>
62 <b>worker_processes 4</b>; 66 <b>worker_processes 4</b>;
63 67
64 http { 68 http {
65 <b>ssl_session_cache shared:SSL:10m</b>; 69 <b>ssl_session_cache shared:SSL:10m</b>;
66 <b>ssl_session_timeout 10m</b>; 70 <b>ssl_session_timeout 10m</b>;
67 71
68 server { 72 server {
69 listen 443; 73 listen 443;
70 server_name www.nginx.com; 74 server_name www.example.com;
71 <b>keepalive_timeout 70</b>; 75 <b>keepalive_timeout 70</b>;
72 76
73 ssl on; 77 ssl on;
74 ssl_certificate www.nginx.com.crt; 78 ssl_certificate www.example.com.crt;
75 ssl_certificate_key www.nginx.com.key; 79 ssl_certificate_key www.example.com.key;
76 ssl_protocols SSLv3 TLSv1; 80 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
77 ssl_ciphers HIGH:!aNULL:!MD5; 81 ssl_ciphers HIGH:!aNULL:!MD5;
78 ... 82 ...
79 </programlisting> 83 </programlisting>
80 </para> 84 </para>
81 85
82 </section> 86 </section>
86 90
87 <para> 91 <para>
88 有些浏览器不接受那些众所周知的证书认证机构签署的证书，而另外一些浏览器却接受它们。这是由于证书签发使用了一些中间认证机构，这些中间机构被众所周知的证书认证机构授权代为签发证书，但是它们自己却不被广泛认知，所以有些客户端不予识别。针对这种情况，证书认证机构提供一个证书链的包裹，用来声明众所周知的认证机构和自己的关系，需要将这个证书链包裹与服务器证书合并成一个文件。在这个文件里，服务器证书需要出现在认证方证书链的前面： 92 有些浏览器不接受那些众所周知的证书认证机构签署的证书，而另外一些浏览器却接受它们。这是由于证书签发使用了一些中间认证机构，这些中间机构被众所周知的证书认证机构授权代为签发证书，但是它们自己却不被广泛认知，所以有些客户端不予识别。针对这种情况，证书认证机构提供一个证书链的包裹，用来声明众所周知的认证机构和自己的关系，需要将这个证书链包裹与服务器证书合并成一个文件。在这个文件里，服务器证书需要出现在认证方证书链的前面：
89 93
90 <programlisting> 94 <programlisting>
91 $ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt 95 $ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
92 </programlisting> 96 </programlisting>
93 97
94 这个文件需要使用<literal>ssl_certificate</literal>指令来引用： 98 这个文件需要使用<link doc="ngx_http_ssl_module.xml" id="ssl_certificate"/>指令来引用：
95 99
96 <programlisting> 100 <programlisting>
97 server { 101 server {
98 listen 443; 102 listen 443;
99 server_name www.nginx.com; 103 server_name www.example.com;
100 ssl on; 104 ssl on;
101 ssl_certificate www.nginx.com.chained.crt; 105 ssl_certificate www.example.com.chained.crt;
102 ssl_certificate_key www.nginx.com.key; 106 ssl_certificate_key www.example.com.key;
103 ... 107 ...
104 } 108 }
105 </programlisting> 109 </programlisting>
106 110
107 如果服务器证书和认证方证书链合并时顺序弄错了，nginx就不能正常启动，而且会显示下面的错误信息： 111 如果服务器证书和认证方证书链合并时顺序弄错了，nginx就不能正常启动，而且会显示下面的错误信息：
108 112
109 <programlisting> 113 <programlisting>
110 SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed 114 SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
111 (SSL: error:0B080074:x509 certificate routines: 115 (SSL: error:0B080074:x509 certificate routines:
112 X509_check_private_key:key values mismatch) 116 X509_check_private_key:key values mismatch)
113 </programlisting> 117 </programlisting>
114 118
115 因为nginx首先需要用私钥去解密服务器证书，而遇到的却是认证方的证书。 119 因为nginx首先需要用私钥去解密服务器证书，而遇到的却是认证方的证书。
141 /OU=ValiCert Class 2 Policy Validation Authority 145 /OU=ValiCert Class 2 Policy Validation Authority
142 /CN=http://www.valicert.com//emailAddress=info@valicert.com 146 /CN=http://www.valicert.com//emailAddress=info@valicert.com
143 ... 147 ...
144 </programlisting> 148 </programlisting>
145 149
146 在这个例子中，www.GoDaddy.com的服务器证书（#0）的受签者（“s”）是被签发机构（“i”）签名的，而这个签发机构又是证书（#1）的受签者，接着证书（#1）的签发机构又是证书（#2）的受签者，最后证书（#2）是被众所周知的签发机构ValiCert, Inc签发。ValiCert, Inc的证书内嵌在浏览器中，被浏览器自动识别。 150 在这个例子中，www.GoDaddy.com的服务器证书（#0）的受签者（“s”）是被签发机构（“i”）签名的，而这个签发机构又是证书（#1）的受签者，接着证书（#1）的签发机构又是证书（#2）的受签者，最后证书（#2）是被众所周知的签发机构ValiCert, Inc签发。ValiCert, Inc的证书内嵌在浏览器中，被浏览器自动识别（这段话神似英国诗《在Jack盖的房子里》里面的内容）。
147 </para> 151 </para>
148 152
149 <para> 153 <para>
150 如果没有加入认证方证书链，那只能看到服务器证书（#0）。 154 如果没有加入认证方证书链，就只会显示服务器证书（#0）。
151 </para> 155 </para>
152 156
153 </section> 157 </section>
154 158
155 159
156 <section id="single_http_https_server" name="统一的HTTP/HTTPS主机"> 160 <section id="single_http_https_server" name="合并HTTP/HTTPS主机">
157 161
158 <para> 162 <para>
159 从开始就将HTTP主机和HTTPS主机分开配置是很好一个很好的实践。虽然它们的功能现在看来是一样的，但是这个情况将来可能会有很大变化，那么合在一起的配置就有问题了。如果HTTP和HTTPS主机配置相同，而又不考虑将来重写配置的话，可以用一个主机配置统一处理HTTP和HTTPS请求。方法是删除<literal>ssl on</literal>的配置项，并在*:443端口添加参数<literal>ssl</literal>： 163 如果HTTP和HTTPS虚拟主机的功能是一致的，可以配置一个虚拟主机，既处理HTTP请求，又处理HTTPS请求。
160 <programlisting> 164 配置的方法是删除<literal>ssl on</literal>的指令，并在*:443端口添加参数<literal>ssl</literal>：
161 server { 165 <programlisting>
162 listen 80; 166 server {
163 listen 443 ssl; 167 listen 80;
164 server_name www.nginx.com; 168 listen 443 ssl;
165 ssl_certificate www.nginx.com.crt; 169 server_name www.example.com;
166 ssl_certificate_key www.nginx.com.key; 170 ssl_certificate www.example.com.crt;
171 ssl_certificate_key www.example.com.key;
167 ... 172 ...
168 } 173 }
169 </programlisting> 174 </programlisting>
170 175
171 <note> 176 <note>
172 在0.8.21版本以前，只有添加了<literal>default</literal>参数的监听端口才能添加<literal>ssl</literal>参数： 177 在0.8.21版本以前，只有添加了<literal>default</literal>参数的监听端口才能添加<literal>ssl</literal>参数：
173 <programlisting> 178 <programlisting>
174 listen 443 default ssl; 179 listen 443 default ssl;
175 </programlisting> 180 </programlisting>
176 </note> 181 </note>
177 </para> 182 </para>
178 183
179 </section> 184 </section>
180 185
181 186
182 <section id="name_based_https_servers" name="基于名字的HTTPS主机"> 187 <section id="name_based_https_servers" name="基于名字的HTTPS主机">
183 188
184 <para> 189 <para>
185 在同一个IP上配置多个HTTPS主机，会出现问题： 190 如果在同一个IP上配置多个HTTPS主机，会出现一个很普遍的问题：
186 191
187 <programlisting> 192 <programlisting>
188 server { 193 server {
189 listen 443; 194 listen 443;
190 server_name www.nginx.com; 195 server_name www.example.com;
191 ssl on; 196 ssl on;
192 ssl_certificate www.nginx.com.crt; 197 ssl_certificate www.example.com.crt;
193 ... 198 ...
194 } 199 }
195 200
196 server { 201 server {
197 listen 443; 202 listen 443;
198 server_name www.nginx.org; 203 server_name www.example.org;
199 ssl on; 204 ssl on;
200 ssl_certificate www.nginx.org.crt; 205 ssl_certificate www.example.org.crt;
201 ... 206 ...
202 } 207 }
203 </programlisting> 208 </programlisting>
204 209
205 使用上面的配置，不论浏览器请求哪个主机，都只会收到默认主机的证书，比方说就是<literal>www.nginx.com</literal>。这是由SSL协议本身的行为引起的。因为SSL规定在建立SSL连接以后，才能发送HTTP请求，所以nginx建立SSL连接时不知道所请求主机的名字，因此，它只会返回默认主机的证书。 210 使用上面的配置，不论浏览器请求哪个主机，都只会收到默认主机<literal>www.example.com</literal>的证书。这是由SSL协议本身的行为引起的——先建立SSL连接，再发送HTTP请求，所以nginx建立SSL连接时不知道所请求主机的名字，因此，它只会返回默认主机的证书。
206 </para> 211 </para>
207 212
208 <para> 213 <para>
209 最古老的也是最稳定的解决方法就是每个HTTPS主机使用不同的IP地址： 214 最古老的也是最稳定的解决方法就是每个HTTPS主机使用不同的IP地址：
210 215
211 <programlisting> 216 <programlisting>
212 server { 217 server {
213 listen 192.168.1.1:443; 218 listen 192.168.1.1:443;
214 server_name www.nginx.com; 219 server_name www.example.com;
215 ssl on; 220 ssl on;
216 ssl_certificate www.nginx.com.crt; 221 ssl_certificate www.example.com.crt;
217 ... 222 ...
218 } 223 }
219 224
220 server { 225 server {
221 listen 192.168.1.2:443; 226 listen 192.168.1.2:443;
222 server_name www.nginx.org; 227 server_name www.example.org;
223 ssl on; 228 ssl on;
224 ssl_certificate www.nginx.org.crt; 229 ssl_certificate www.example.org.crt;
225 ... 230 ...
226 } 231 }
227 </programlisting> 232 </programlisting>
228 </para> 233 </para>
229 234
232 237
233 <section id="certificate_with_several_names" 238 <section id="certificate_with_several_names"
234 name="带有多个主机名的SSL证书"> 239 name="带有多个主机名的SSL证书">
235 240
236 <para> 241 <para>
237 也有其他一些方法可以实现多个HTTPS主机共享一个IP地址，但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书，比如<literal>www.nginx.com</literal>和<literal>www.nginx.org</literal>。这种方法的限制是“SubjectAltName”字段的长度。 242 也有其他一些方法可以实现多个HTTPS主机共享一个IP地址，但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书，比如<literal>www.example.com</literal>和<literal>www.example.org</literal>。但是，“SubjectAltName”字段的长度有限制。
238 </para> 243 </para>
239 244
240 <para> 245 <para>
241 另一种方式是使用主机名中含有通配符的证书，比如<literal>*.nginx.org</literal>。这个证书匹配<literal>www.nginx.org</literal>，但是不匹配<literal>nginx.org</literal>和<literal>www.sub.nginx.org</literal>。这两种方法可以结合在一起——使用在“SubjectAltName”字段中存放的多个名字的证书，这些名字既可以是确切的名字，也可以是通配符，比如<literal>nginx.org</literal>和<literal>*.nginx.org</literal>。 246 另一种方式是使用主机名中含有通配符的证书，比如<literal>*.example.org</literal>。这个证书匹配<literal>www.example.org</literal>，但是不匹配<literal>example.org</literal>和<literal>www.sub.example.org</literal>。这两种方法可以结合在一起——使用在“SubjectAltName”字段中存放的多个名字的证书，这些名字既可以是确切的名字，也可以是通配符，比如<literal>example.org</literal>和<literal>*.example.org</literal>。
242 </para> 247 </para>
243 248
244 <para> 249 <para>
245 最好将带有多个名字的证书和它的密钥文件配置在http配置块中，这样可以只保存一份内容拷贝，所有主机的配置都从中继承： 250 最好将带有多个名字的证书和它的密钥文件配置在<i>http</i>配置块中，这样可以只保存一份内容拷贝，所有主机的配置都从中继承：
246 251
247 <programlisting> 252 <programlisting>
248 ssl_certificate common.crt; 253 ssl_certificate common.crt;
249 ssl_certificate_key common.key; 254 ssl_certificate_key common.key;
250 255
251 server { 256 server {
252 listen 443; 257 listen 443;
253 server_name www.nginx.com; 258 server_name www.example.com;
254 ssl on; 259 ssl on;
255 ... 260 ...
256 } 261 }
257 262
258 server { 263 server {
259 listen 443; 264 listen 443;
260 server_name www.nginx.org; 265 server_name www.example.org;
261 ssl on; 266 ssl on;
262 ... 267 ...
263 } 268 }
264 </programlisting> 269 </programlisting>
265 </para> 270 </para>
266 271
268 273
269 274
270 <section id="sni" name="主机名指示"> 275 <section id="sni" name="主机名指示">
271 276
272 <para> 277 <para>
273 在一个IP上运行多个HTTPS主机的更通用的方案是<link url="http://en.wikipedia.org/wiki/Server_Name_Indication">TLSv1.1 主机名指示扩展</link>（SNI，RFC3546），它允许浏览器和服务器进行SSL握手时，将请求的主机名传递服务器，因此服务器可以知道使用哪一个证书来服务这个连接。但SNI只得到有限的浏览器的支持。下面列举支持SNI的浏览器最低版本和平台信息： 278 在一个IP上运行多个HTTPS主机的更通用的方案是<link url="http://en.wikipedia.org/wiki/Server_Name_Indication">TLS主机名指示扩展</link>（SNI，RFC6066），它允许浏览器和服务器进行SSL握手时，将请求的主机名传递给服务器，因此服务器可以知道使用哪一个证书来服务这个连接。但SNI只得到有限的浏览器的支持。下面列举支持SNI的浏览器最低版本和平台信息：
274 </para> 279 </para>
275 280
281 <para>
276 <list type="bullet"> 282 <list type="bullet">
277 283
278 <listitem> 284 <listitem>
279 Opera 8.0； 285 Opera 8.0；
280 </listitem> 286 </listitem>
294 <listitem> 300 <listitem>
295 Chrome（Windows版需要最低Vista操作系统）。 301 Chrome（Windows版需要最低Vista操作系统）。
296 </listitem> 302 </listitem>
297 303
298 </list> 304 </list>
305 <note>
306 通过SNI只能传递域名，但是，当请求中包含可读的IP地址时，某些浏览器将服务器的IP地址作为服务器的名字进行了传送。这是一个错误，大家不应该依赖于这个。
307 </note>
308 </para>
299 309
300 <para> 310 <para>
301 为了在nginx中使用SNI，那么无论是在编译nginx时使用的OpenSSL类库，还是在运行nginx时使用的OpenSSL运行库，都必须支持SNI。从0.9.8f版本开始，OpenSSL通过<nobr>&ldquo;--enable-tlsext&rdquo;</nobr>配置选项加入SNI支持，从0.9.8j版本开始，此选项成为默认选项。当nginx被编译成支持SNI时，在使用“-V”选项运行时会显示如下信息： 311 为了在nginx中使用SNI，那么无论是在编译nginx时使用的OpenSSL类库，还是在运行nginx时使用的OpenSSL运行库，都必须支持SNI。从0.9.8f版本开始，OpenSSL通过<nobr>&ldquo;--enable-tlsext&rdquo;</nobr>配置选项加入SNI支持，从0.9.8j版本开始，此选项成为默认选项。当nginx被编译成支持SNI时，在使用“-V”选项运行时会显示如下信息：
302 312
303 <programlisting> 313 <programlisting>
327 <listitem> 337 <listitem>
328 从0.8.21和0.7.62版本开始，使用“-V”选项运行nginx时，将显示SNI支持状态信息。 338 从0.8.21和0.7.62版本开始，使用“-V”选项运行nginx时，将显示SNI支持状态信息。
329 </listitem> 339 </listitem>
330 340
331 <listitem> 341 <listitem>
332 从0.7.14版本开始，<literal>listen</literal>指令支持<literal>ssl</literal>参数。 342 从0.7.14版本开始，<link doc="ngx_http_core_module.xml" id="listen"/>指令支持<literal>ssl</literal>参数。
333 </listitem> 343 </listitem>
334 344
335 <listitem> 345 <listitem>
336 从0.5.32版本开始，支持SNI。 346 从0.5.32版本开始，支持SNI。
337 </listitem> 347 </listitem>
345 355
346 <para> 356 <para>
347 <list type="bullet"> 357 <list type="bullet">
348 358
349 <listitem> 359 <listitem>
350 0.7.65、0.8.19及以后版本，默认SSL协议是SSLv3和TLSv1。 360 0.7.65、0.8.19及以后版本，默认SSL协议是SSLv3、TLSv1、TLSc1.1和TLSv1.2（如果OpenSSL库支持）。
351 </listitem> 361 </listitem>
352 362
353 <listitem> 363 <listitem>
354 0.7.64、0.8.18及以前版本，默认SSL协议是SSLv2、SSLv3和TLSv1。 364 0.7.64、0.8.18及以前版本，默认SSL协议是SSLv2、SSLv3和TLSv1。
355 </listitem> 365 </listitem>