Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
btwise
openssl
提交
37f599bc
O
openssl
项目概览
btwise
/
openssl
通知
1
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
O
openssl
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
37f599bc
编写于
7月 31, 2001
作者:
L
Lutz Jänicke
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Reworked manual pages with a lot of input from Bodo Moeller.
上级
8408f4fb
变更
3
显示空白变更内容
内联
并排
Showing
3 changed file
with
121 addition
and
71 deletion
+121
-71
doc/ssl/SSL_CTX_set_options.pod
doc/ssl/SSL_CTX_set_options.pod
+26
-11
doc/ssl/SSL_CTX_set_tmp_dh_callback.pod
doc/ssl/SSL_CTX_set_tmp_dh_callback.pod
+41
-17
doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod
doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod
+54
-43
未找到文件。
doc/ssl/SSL_CTX_set_options.pod
浏览文件 @
37f599bc
...
...
@@ -17,10 +17,10 @@ SSL_CTX_set_options, SSL_set_options, SSL_CTX_get_options, SSL_get_options - man
=head1 DESCRIPTION
SSL_CTX_set_options() adds the options set via bitmask in B<options> to B<ctx>.
Options already set before are not cleared
.
Options already set before are not cleared
!
SSL_set_options() adds the options set via bitmask in B<options> to B<ssl>.
Options already set before are not cleared
.
Options already set before are not cleared
!
SSL_CTX_get_options() returns the options set for B<ctx>.
...
...
@@ -32,7 +32,12 @@ The behaviour of the SSL library can be changed by setting several options.
The options are coded as bitmasks and can be combined by a logical B<or>
operation (|). Options can only be added but can never be reset.
During a handshake, the option settings of the SSL object used. When
SSL_CTX_set_options() and SSL_set_options() affect the (external)
protocol behaviour of the SSL library. The (internal) behaviour of
the API can be changed by using the similar
L<SSL_CTX_set_modes(3)|SSL_CTX_set_modes(3)> and SSL_set_modes() functions.
During a handshake, the option settings of the SSL object are used. When
a new SSL object is created from a context using SSL_new(), the current
option setting is copied. Changes to B<ctx> do not affect already created
SSL objects. SSL_clear() does not affect the settings.
...
...
@@ -122,13 +127,27 @@ The following B<modifying> options are available:
=item SSL_OP_SINGLE_DH_USE
Always create a new key when using temporary DH parameters
Always create a new key when using temporary
/ephemeral
DH parameters
(see L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>).
This option must be used to prevent small subgroup attacks, when
the DH parameters were not generated using "strong" primes
(e.g. when using DSA-parameters, see L<dhparam(1)|dhparam(1)>).
If "strong" primes were used, it is not strictly necessary to generate
a new DH key during each handshake but it is also recommendet.
SSL_OP_SINGLE_DH_USE should therefore be enabled whenever
temporary/ephemeral DH parameters are used.
=item SSL_OP_EPHEMERAL_RSA
Al
so
use ephemeral (temporary) RSA key when doing RSA operations
Al
ways
use ephemeral (temporary) RSA key when doing RSA operations
(see L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>).
According to the specifications this is only done, when a RSA key
can only be used for signature operations (namely under export ciphers
with restricted RSA keylength). By setting this option, ephemeral
RSA keys are always used. This option breaks compatibility with the
SSL/TLS specifications and may lead to interoperability problems with
clients and should therefore never be used. Ciphers with EDH (ephemeral
Diffie-Hellman) key exchange should be used instead.
=item SSL_OP_CIPHER_SERVER_PREFERENCE
...
...
@@ -152,11 +171,6 @@ If we accept a netscape connection, demand a client cert, have a
non-self-sighed CA which does not have it's CA in netscape, and the
browser has a cert, it will crash/hang. Works for 3.x and 4.xbeta
=item SSL_OP_NON_EXPORT_FIRST
On servers try to use non-export (stronger) ciphers first. This option does
not work under all circumstances (in the code it is declared "broken").
=item SSL_OP_NETSCAPE_DEMO_CIPHER_CHANGE_BUG
...
...
...
@@ -186,7 +200,8 @@ SSL_CTX_get_options() and SSL_get_options() return the current bitmask.
L<ssl(3)|ssl(3)>, L<SSL_new(3)|SSL_new(3)>, L<SSL_clear(3)|SSL_clear(3)>,
L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>,
L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>
L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>,
L<dhparam(1)|dhparam(1)>
=head1 HISTORY
...
...
doc/ssl/SSL_CTX_set_tmp_dh_callback.pod
浏览文件 @
37f599bc
...
...
@@ -36,10 +36,11 @@ These functions apply to SSL/TLS servers only.
=head1 NOTES
When using a cipher with RSA authentication, an ephemeral DH key exchange
can take place. Ciphers with DSA keys always use ephemeral DH keys as well
as anonymous ciphers. In this case
the session data are negotiated using the
can take place. Ciphers with DSA keys always use ephemeral DH keys as well
.
In these cases,
the session data are negotiated using the
ephemeral/temporary DH key and the key supplied and certified
by the certificate chain is only used for signing.
Anonymous ciphers (without a permanent server key) also use ephemeral DH keys.
Using ephemeral DH key exchange yields forward secrecy, as the connection
can only be decrypted, when the DH key is known. By generating a temporary
...
...
@@ -49,26 +50,48 @@ even if he gets hold of the normal (certified) key, as this key was
only used for signing.
In order to perform a DH key exchange the server must use a DH group
(DH parameters) and generate a DH key. The server will automatically
generate the DH key when required, as it is computationally cheap
(retrieve a random number). The server will reuse the DH key for further
connections, unless the SSL_OP_SINGLE_DH_USE option of
L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)> is set, in which case
a new DH key for each negotiation will be generated.
(DH parameters) and generate a DH key. The server will always generate a new
DH key during the negotiation, when the DH parameters are supplied via
callback and/or when the SSL_OP_SINGLE_DH_USE option of
L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)> is set. It will
immediatly create a DH key, when DH parameters are supplied via
SSL_CTX_set_tmp_dh() and SSL_OP_SINGLE_DH_USE is not set. In this case,
it may happen that a key is generated on initialization without later
being needed, while on the other hand the computer time during the
negotiation is being saved.
If "strong" primes were used to generate the DH parameters, it is not strictly
necessary to generate a new key for each handshake but it does improve forward
secrecy. If it is not assured, that "strong" primes were used (see especially
the section about DSA parameters below), SSL_OP_SINGLE_DH_USE must be used
in order to prevent small subgroup attacks. Always using SSL_OP_SINGLE_DH_USE
has an impact on the computer time needed during negotiation, but it is not
very large, so application authors/users should consider to always enable
this option.
As generating DH parameters is extremely time consuming, an application
should not generate the parameters on the fly but supply the parameters.
DH parameters can be reused, as the actual key is newly generated during
the negotiation. The risk in reusing DH parameters is that an attacker
may specialize on a very often used DH group. Therefore application authors
should not copy the DH parameters from other applications or the OpenSSL
example application, if they compile in parameters, but generate their
own set of parameters using e.g. the openssl L<dhparam(1)|dhparam(1)>
application with the B<-C> option. An application may also generate
its own set of DH parameters during the installation procedure on a specific
host, so that each host uses different parameters.
An application my either directly specify the DH parameters or
may specialize on a very often used DH group. Applications should therefore
generate their own DH paramaters during the installation process using the
openssl L<dhparam(1)|dhparam(1)> application. In order to reduce the computer
time needed for this generation, it is possible to use DSA parameters
instead (see L<dhparam(1)|dhparam(1)>), but in this case SSL_OP_SINGLE_DH_USE
is mandatory.
Application authors may compile in DH parameters. Files dh512.pem,
dh1024.pem, dh2048.pem, and dh4096 in the 'apps' directory of current
version of the OpenSSL distribution contain the 'SKIP' DH parameters,
which use safe primes and were generated verifiably pseudo-randomly.
These files can be converted into C code using the B<-C> option of the
L<dhparam(1)|dhparam(1)> application.
Authors may also generate their own set of parameters using
L<dhparam(1)|dhparam(1)>, but a user may not be sure how the parameters were
generated. The generation of DH parameters during installation is therefore
recommended.
An application may either directly specify the DH parameters or
can supply the DH parameters via a callback function. The callback approach
has the advantage, that the callback may supply DH parameters for different
key lengths.
...
...
@@ -140,6 +163,7 @@ on failure. Check the error queue to find out the reason of failure.
=head1 SEE ALSO
L<ssl(3)|ssl(3)>, L<SSL_CTX_set_cipher_list(3)|SSL_CTX_set_cipher_list(3)>,
L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>,
L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>,
L<ciphers(1)|ciphers(1)>, L<dhparam(1)|dhparam(1)>
...
...
doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod
浏览文件 @
37f599bc
...
...
@@ -24,20 +24,24 @@ SSL_CTX_set_tmp_rsa_callback, SSL_CTX_set_tmp_rsa, SSL_CTX_need_tmp_rsa, SSL_set
SSL_CTX_set_tmp_rsa_callback() sets the callback function for B<ctx> to be
used when a temporary/ephemeral RSA key is required to B<tmp_rsa_callback>.
The callback is inherited by all B<ssl> objects created from B<ctx>.
The callback is inherited by all SSL objects newly created from B<ctx>
with <SSL_new(3)|SSL_new(3)>. Already created SSL objects are not affected.
SSL_CTX_set_tmp_rsa() sets the temporary/ephemeral RSA key to be used to be
B<rsa>. The key is inherited by all B<ssl> objects created from B<ctx>.
B<rsa>. The key is inherited by all SSL objects newly created from B<ctx>
with <SSL_new(3)|SSL_new(3)>. Already created SSL objects are not affected.
SSL_CTX_need_tmp_rsa() returns 1, if a temporay/ephemeral RSA key is needed,
because a RSA key with a keysize larger than 512 bits is installed.
SSL_CTX_need_tmp_rsa() returns 1, if a temporay/ephemeral RSA key is needed
for RSA-based strength-limited 'exportable' ciphersuites because a RSA key
with a keysize larger than 512 bits is installed.
SSL_set_tmp_rsa_callback() sets the callback only for B<ssl>.
SSL_set_tmp_rsa() sets the key only for B<ssl>.
SSL_need_tmp_rsa() returns 1, if a temporay/ephemeral RSA key is needed,
because a RSA key with a keysize larger than 512 bits is installed.
for RSA-based strength-limited 'exportable' ciphersuites because a RSA key
with a keysize larger than 512 bits is installed.
These functions apply to SSL/TLS servers only.
...
...
@@ -48,32 +52,42 @@ can take place. In this case the session data are negotiated using the
ephemeral/temporary RSA key and the RSA key supplied and certified
by the certificate chain is only used for signing.
Under previous export restrictions, ciphers with RSA keys shorter (512 bits)
than the usual key length of 1024 bits were created. To use these ciphers
with RSA keys of usual length, an ephemeral key exchange must be performed,
as the normal (certified) key cannot be directly used.
Using ephemeral RSA key exchange yields forward secrecy, as the connection
can only be decrypted, when the RSA key is known. By generating a temporary
RSA key inside the server application that is lost when the application
is left, it becomes impossible for an attacker to decrypt past sessions,
even if he gets hold of the normal (certified) RSA key, as this key was
only used for signing. The downside is that creating a RSA key is
computationally expensive. On OpenSSL servers ephemeral RSA key exchange
is therefore disabled by default and must be explicitly enabled using the
SSL_OP_EPHEMERAL_RSA option of
L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>, except for certain
export ciphers.
Under previous export restrictions, ciphers with RSA keys shorter (512 bits)
than the usual key length of 1024 bits were created. To use these ciphers
with RSA keys of usual length, an ephemeral key exchange must be performed,
as the normal (certified) key cannot be used.
An application my either directly specify the key or
can supply the key via a callback function. The callback approach has
the advantage, that the callback may generate the key only in case it is
actually needed. As the generation of a RSA key is however costly, it
will lead to a significant delay in the handshake procedure.
Another advantage of the callback function is that it can supply keys
of different size (e.g. for SSL_OP_EPHEMERAL_RSA usage) while the
explicit setting of the key is only useful for key size of 512 bits
to satisfy the export restricted ciphers and does give away key length
used for signing only. The downside is that creating a RSA key is
computationally expensive.
Additionally, the use of ephemeral RSA key exchange is only allowed in
the TLS standard, when the RSA key can be used for signing only, that is
for export ciphers. Using ephemeral RSA key exchange for other purposes
violates the standard and can break interoperability with clients.
It is therefore strongly recommended to not use ephemeral RSA key
exchange and use EDH (Ephemeral Diffie-Hellman) key exchange instead
in order to achieve forward secrecy (see
L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>).
On OpenSSL servers ephemeral RSA key exchange is therefore disabled by default
and must be explicitly enabled using the SSL_OP_EPHEMERAL_RSA option of
L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>, violating the TLS/SSL
standard. When ephemeral RSA key exchange is required for export ciphers,
it will automatically be used without this option!
An application may either directly specify the key or can supply the key via
a callback function. The callback approach has the advantage, that the
callback may generate the key only in case it is actually needed. As the
generation of a RSA key is however costly, it will lead to a significant
delay in the handshake procedure. Another advantage of the callback function
is that it can supply keys of different size (e.g. for SSL_OP_EPHEMERAL_RSA
usage) while the explicit setting of the key is only useful for key size of
512 bits to satisfy the export restricted ciphers and does give away key length
if a longer key would be allowed.
The B<tmp_rsa_callback> is called with the B<keylength> needed and
...
...
@@ -83,7 +97,7 @@ ephemeral RSA key exchange is performed with an export cipher.
=head1 EXAMPLES
Generate temporary RSA keys to prepare ephemeral RSA key exchange. As the
generation of a RSA key costs a lot of computer time,
it is
saved for later
generation of a RSA key costs a lot of computer time,
they
saved for later
reuse. For demonstration purposes, two keys for 512 bits and 1024 bits
respectively are generated.
...
...
@@ -91,19 +105,15 @@ respectively are generated.
/* Set up ephemeral RSA stuff */
RSA *rsa_512 = NULL;
RSA *rsa_1024 = NULL;
if (prepare_export_in_advance || always_use_ephemeral_rsa) {
rsa_512 = RSA_generate_key(512,RSA_F4,NULL,NULL);
if (rsa_512 == NULL)
evaluate_error_queue();
}
if (always_use_ephemeral_rsa) {
/* Only spend the time to generate the key, if it will actually be
needed */
rsa_1024 = RSA_generate_key(1024,RSA_F4,NULL,NULL);
if (rsa_1024 == NULL)
evaluate_error_queue();
SSL_CTX_set_options(SSL_OP_EPHEMERAL_RSA);
}
...
RSA *tmp_rsa_callback(SSL *s, int is_export, int keylength)
...
...
@@ -114,8 +124,8 @@ respectively are generated.
case 512:
if (rsa_512)
rsa_tmp = rsa_512;
else { /* generate on the fly */
rsa_tmp = RSA_generate_key(
512
,RSA_F4,NULL,NULL);
else { /* generate on the fly
, should not happen in this example
*/
rsa_tmp = RSA_generate_key(
keylength
,RSA_F4,NULL,NULL);
rsa_512 = rsa_tmp; /* Remember for later reuse */
}
break;
...
...
@@ -123,7 +133,7 @@ respectively are generated.
if (rsa_1024)
rsa_tmp=rsa_1024;
else
this_should_never_happen_as_we_are_prepared
();
should_not_happen_in_this_example
();
break;
default:
/* Generating a key on the fly is very costly, so use what is there */
...
...
@@ -150,6 +160,7 @@ RSA key is needed and 0 otherwise.
L<ssl(3)|ssl(3)>, L<SSL_CTX_set_cipher_list(3)|SSL_CTX_set_cipher_list(3)>,
L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>,
L<ciphers(1)|ciphers(1)>
L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>,
L<SSL_new(3)|SSL_new(3)>, L<ciphers(1)|ciphers(1)>
=cut
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录