The "-unix <path>" argument allows s_server and s_client to use a unix
domain socket in the filesystem instead of IPv4 ("-connect", "-port",
"-accept", etc). If s_server exits gracefully, such as when "-naccept"
is used and the requested number of SSL/TLS connections have occurred,
then the domain socket file is removed. On ctrl-C, it is likely that
the stale socket file will be left over, such that s_server would
normally fail to restart with the same arguments. For this reason,
s_server also supports an "-unlink" option, which will clean up any
stale socket file before starting.
If you have any reason to want encrypted IPC within an O/S instance,
this concept might come in handy. Otherwise it just demonstrates that
there is nothing about SSL/TLS that limits it to TCP/IP in any way.
(There might also be benchmarking and profiling use in this path, as
unix domain sockets are much lower overhead than connecting over local
IP addresses).
Signed-off-by: Geoff Thorpe <geoff@openssl.org>
There are certainly many more constifiable strings in the various
interfaces, which I hope to get to eventually.
Signed-off-by: Geoff Thorpe <geoff@openssl.org>
Use bufsiz - 1 not BUFSIZ - 1 when prompting for a password in
the openssl utility.
Thanks to Rob Mackinnon, Leviathan Security for reporting this issue.
New function ssl_cipher_disabled.
Check for disabled client ciphers using ssl_cipher_disabled.
New function to return only supported ciphers.
New option to ciphers utility to print only supported ciphers.
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.
Add option to set an alternative to the default hmacWithSHA1 PRF
for PKCS#8 private key encryptions. This is used automatically
by PKCS8_encrypt if the nid specified is a PRF.
Add option to pkcs8 utility.
Update docs.
(cherry picked from commit b60272b01f)
Windows 8 SDKs complain that GetVersion() is deprecated.
We only use GetVersion like this:
(GetVersion() < 0x80000000)
which checks if the Windows version is NT based. Use a macro check_winnt()
which uses GetVersion() on older SDK versions and true otherwise.
New flags to build certificate chains. The can be used to rearrange
the chain so all an application needs to do is add all certificates
in arbitrary order and then build the chain to check and correct them.
Add verify error code when building chain.
Update docs.
If you use "-newkey rsa" it's supposed to read the default number of bits from the
config file. However the value isn't used to generate the key, but it does
print it's generating such a key. The set_keygen_ctx() doesn't call
EVP_PKEY_CTX_set_rsa_keygen_bits() and you end up with the default set in
pkey_rsa_init() (1024). Afterwards the number of bits gets read from the config
file, but nothing is done with that anymore.
We now read the config first and use the value from the config file when no size
is given.
PR: 2592
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.
Experimental support for encrypt then mac from
draft-gutmann-tls-encrypt-then-mac-02.txt
To enable it set the appropriate extension number (0x10 for the test server)
using e.g. -DTLSEXT_TYPE_encrypt_then_mac=0x10
For non-compliant peers (i.e. just about everything) this should have no
effect.
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.
* Many XMPP servers are configured with multiple domains (virtual hosts)
* In order to establish successfully the TLS connection you have to specify
which virtual host you are trying to connect.
* Test this, for example with ::
* Fail:
openssl s_client -connect talk.google.com:5222 -starttls xmpp
* Works:
openssl s_client -connect talk.google.com:5222 -starttls xmpp -xmpphost gmail.com
* When the host used in "-connect" is not what the remote XMPP server expects
the server will return an error like this:
<stream:error>
<host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
* But the actual code will stay on the loop forever because the stop condition
"/stream:features>" will never happen,
* Make this more robust: The stop condition should be that BIO_read failed
* Test if for example with ::
openssl s_client -connect random.jabb3r.net:5222 -starttls xmpp
* Some XMPP Servers (OpenFire) use double quotes.
* This makes s_client starttls work with this servers.
* Tested with OpenFire servers from http://xmpp.net/ ::
openssl s_client -connect coderollers.com:5222 -starttls xmpp