- 17 12月, 2014 1 次提交
-
-
由 Richard Levitte 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org>
-
- 16 12月, 2014 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NEmilia Käsper <emilia@openssl.org>
-
- 04 12月, 2014 1 次提交
-
-
由 Kurt Roeckx 提交于
The only support for SSLv2 left is receiving a SSLv2 compatible client hello. Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 15 10月, 2014 1 次提交
-
-
由 Bodo Moeller 提交于
Reviewed-by: NStephen Henson <steve@openssl.org>
-
- 29 8月, 2014 1 次提交
-
-
由 Dr. Stephen Henson 提交于
Since sanity checks are performed for all custom extensions the serverinfo checks are no longer needed. Reviewed-by: NEmilia Käsper <emilia@openssl.org>
-
- 16 8月, 2014 1 次提交
-
-
由 Hubert Kario 提交于
While RFC6367 focuses on Camellia-GCM cipher suites, it also adds a few cipher suites that use SHA-2 based HMAC that can be very easily added. Tested against gnutls 3.3.5 PR#3443 Reviewed-by: NTim Hudson <tjh@openssl.org>
-
- 09 8月, 2014 1 次提交
-
-
由 Dr. Stephen Henson 提交于
The addition of SRP authentication needs to be checked in various places to work properly. Specifically: A certificate is not sent. A certificate request must not be sent. Server key exchange message must not contain a signature. If appropriate SRP authentication ciphersuites should be chosen. Reviewed-by: NMatt Caswell <matt@openssl.org>
-
- 30 6月, 2014 1 次提交
-
-
由 Ben Laurie 提交于
-
- 28 6月, 2014 1 次提交
-
-
由 PK 提交于
PR#2800
-
- 09 6月, 2014 2 次提交
-
-
由 Dr. Stephen Henson 提交于
SRP ciphersuites do not have no authentication. They have authentication based on SRP. Add new SRP authentication flag and cipher string.
-
由 Dr. Stephen Henson 提交于
Fix strength_bits to 112 for 3DES.
-
- 28 3月, 2014 2 次提交
-
-
由 Dr. Stephen Henson 提交于
Security callback: selects which parameters are permitted including sensible defaults based on bits of security. The "parameters" which can be selected include: ciphersuites, curves, key sizes, certificate signature algorithms, supported signature algorithms, DH parameters, SSL/TLS version, session tickets and compression. In some cases prohibiting the use of a parameters will mean they are not advertised to the peer: for example cipher suites and ECC curves. In other cases it will abort the handshake: e.g DH parameters or the peer key size. Documentation to follow...
-
由 Dr. Stephen Henson 提交于
Add auto DH parameter support. This is roughly equivalent to the ECDH auto curve selection but for DH. An application can just call SSL_CTX_set_auto_dh(ctx, 1); and appropriate DH parameters will be used based on the size of the server key. Unlike ECDH there is no way a peer can indicate the range of DH parameters it supports. Some peers cannot handle DH keys larger that 1024 bits for example. In this case if you call: SSL_CTX_set_auto_dh(ctx, 2); Only 1024 bit DH parameters will be used. If the server key is 7680 bits or more in size then 8192 bit DH parameters will be used: these will be *very* slow. The old export ciphersuites aren't supported but those are very insecure anyway.
-
- 22 2月, 2014 1 次提交
-
-
由 Dr. Stephen Henson 提交于
-
- 06 2月, 2014 4 次提交
-
-
由 Dr. Stephen Henson 提交于
-
由 Scott Deboy 提交于
Whitespace fixes
-
由 Scott Deboy 提交于
If multiple TLS extensions are expected but not received, the TLS extension and supplemental data 'generate' callbacks are the only chance for the receive-side to trigger a specific TLS alert during the handshake. Removed logic which no-op'd TLS extension generate callbacks (as the generate callbacks need to always be called in order to trigger alerts), and updated the serverinfo-specific custom TLS extension callbacks to track which custom TLS extensions were received by the client, where no-ops for 'generate' callbacks are appropriate.
-
由 Dr. Stephen Henson 提交于
If an application calls the macro SSL_CTX_get_extra_chain_certs return either the old "shared" extra certificates or those associated with the current certificate. This means applications which call SSL_CTX_use_certificate_chain_file and retrieve the additional chain using SSL_CTX_get_extra_chain_certs will still work. An application which only wants to check the shared extra certificates can call the new macro SSL_CTX_get_extra_chain_certs_only
-
- 03 2月, 2014 1 次提交
-
-
由 Dr. Stephen Henson 提交于
New ctrl sets current certificate based on certain criteria. Currently two options: set the first valid certificate as current and set the next valid certificate as current. Using these an application can iterate over all certificates in an SSL_CTX or SSL structure.
-
- 09 1月, 2014 4 次提交
-
-
由 Daniel Kahn Gillmor 提交于
Replace the full ciphersuites with "EDH-" in their labels with "DHE-" so that all DHE ciphersuites are referred to in the same way. Leave backward-compatible aliases for the ciphersuites in question so that configurations which specify these explicitly will continue working.
-
由 Daniel Kahn Gillmor 提交于
This change normalizes the SSL_CK_DHE_ #defines to use the common term "DHE", while permitting older code that uses the more uncommon "EDH" constants to compile properly.
-
由 Daniel Kahn Gillmor 提交于
DHE is the standard term used by the RFCs and by other TLS implementations. It's useful to have the internal variables use the standard terminology. This patch leaves a synonym SSL_kEDH in place, though, so that older code can still be built against it, since that has been the traditional API. SSL_kEDH should probably be deprecated at some point, though.
-
由 Daniel Kahn Gillmor 提交于
ECDHE is the standard term used by the RFCs and by other TLS implementations. It's useful to have the internal variables use the standard terminology. This patch leaves a synonym SSL_kEECDH in place, though, so that older code can still be built against it, since that has been the traditional API. SSL_kEECDH should probably be deprecated at some point, though.
-
- 14 11月, 2013 1 次提交
-
-
由 Rob Stradling 提交于
PR#3169 This patch, which currently applies successfully against master and 1_0_2, adds the following functions: SSL_[CTX_]select_current_cert() - set the current certificate without disturbing the existing structure. SSL_[CTX_]get0_chain_certs() - get the current certificate's chain. SSL_[CTX_]clear_chain_certs() - clear the current certificate's chain. The patch also adds these functions to, and fixes some existing errors in, SSL_CTX_add1_chain_cert.pod.
-
- 06 11月, 2013 1 次提交
-
-
由 Dr. Stephen Henson 提交于
Enable PSK ciphersuites with AES or DES3 in FIPS mode.
-
- 13 9月, 2013 2 次提交
-
-
由 Rob Stradling 提交于
-
由 Rob Stradling 提交于
-
- 06 9月, 2013 1 次提交
-
-
由 Scott Deboy 提交于
Add callbacks supporting generation and retrieval of supplemental data entries, facilitating RFC 5878 (TLS auth extensions) Removed prior audit proof logic - audit proof support was implemented using the generic TLS extension API Tests exercising the new supplemental data registration and callback api can be found in ssltest.c. Implemented changes to s_server and s_client to exercise supplemental data callbacks via the -auth argument, as well as additional flags to exercise supplemental data being sent only during renegotiation.
-
- 05 9月, 2013 1 次提交
-
-
由 Rob Stradling 提交于
OS X 10.8..10.8.3 has broken support for ECDHE-ECDSA ciphers.
-
- 18 8月, 2013 2 次提交
-
-
由 Dr. Stephen Henson 提交于
-
由 Dr. Stephen Henson 提交于
-
- 22 7月, 2013 1 次提交
-
-
由 Adam Langley 提交于
This change adds support for ALPN[1] in OpenSSL. ALPN is the IETF blessed version of NPN and we'll be supporting both ALPN and NPN for some time yet. [1] https://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00 Conflicts: ssl/ssl3.h ssl/t1_lib.c
-
- 13 6月, 2013 1 次提交
-
-
由 Trevor 提交于
Contributed by Trevor Perrin.
-
- 28 3月, 2013 1 次提交
-
-
由 Dr. Stephen Henson 提交于
Port TLS 1.2 GCM code to DTLS. Enable use of TLS 1.2 only ciphers when in DTLS 1.2 mode too.
-
- 18 3月, 2013 2 次提交
-
-
由 Dr. Stephen Henson 提交于
Use the enc_flags field to determine whether we should use explicit IV, signature algorithms or SHA256 default PRF instead of hard coding which versions support each requirement.
-
由 Dr. Stephen Henson 提交于
Revise DTLS code. There was a *lot* of code duplication in the DTLS code that generates records. This makes it harder to maintain and sometimes a TLS update is omitted by accident from the DTLS code. Specifically almost all of the record generation functions have code like this: some_pointer = buffer + HANDSHAKE_HEADER_LENGTH; ... Record creation stuff ... set_handshake_header(ssl, SSL_MT_SOMETHING, message_len); ... write_handshake_message(ssl); Where the "Record creation stuff" is identical between SSL/TLS and DTLS or in some cases has very minor differences. By adding a few fields to SSL3_ENC to include the header length, some flags and function pointers for handshake header setting and handshake writing the code can cope with both cases. Note: although this passes "make test" and some simple DTLS tests there may be some minor differences in the DTLS code that have to be accounted for.
-
- 27 11月, 2012 1 次提交
-
-
由 Dr. Stephen Henson 提交于
-
- 22 11月, 2012 1 次提交
-
-
由 Dr. Stephen Henson 提交于
-
- 30 9月, 2012 1 次提交
-
-
由 Dr. Stephen Henson 提交于
a ciphersuite to position the SCSV value in different places for testing purposes.
-
- 12 9月, 2012 1 次提交
-
-
由 Dr. Stephen Henson 提交于
client hello message. Previously this could only be retrieved on an initial connection and it was impossible to determine the cipher IDs of any uknown ciphersuites.
-