Re: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec

[Jeff Wieland]

Dennis Clarke wrote:



Have you tried running Oracle's builds of OpenSSL?  They do the same
thing on the UltraSPARC 2e:


This is officially a bug. I'll file it and start looking into this one.

Very odd.

I will try this on a few other RISC architectures and see what I see. 
Starting with Power6.


Dennis


It's been a while for this :-).

I'm thinking that this is a Solaris bug.  Have you opened a ticket with 
Oracle about it?
I just patched one of my UltraSPARC 2e systems with the latest patches, 
and the problem

remains.

It's still easy to demonstrate:

On UltraSPARC 3i:

$ /bin/time tar cf /dev/null /opt/solstudio12.2

real   48.7
user0.5
sys 4.4

On UltraSPARC 2e:

$ /bin/time tar cf /dev/null /opt/solstudio12.2

real 1:08.1
user0.0
sys 0.0

On the UltraSPARC 2e (in this case a Sun Blade 150), the user and sys
times shouldn't be 0.0.

--
Jeff Wieland, UNIX/Network Systems Administrator
Purdue University IT Infrastructure Services UNIX Platforms


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] “no shared cipher” at ssl_accept, why?

[jockep]

Have googled a lot, not found any answer to the following problem: Created
server code and client code, but get

error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

at the server when doing SSL_connect.

The code below is narrowed down to the sequence of the SSL / socket related
function calls only. Error handling code has been applied where applicable
to make sure calls before SSL_accept / SSL_connect does not return any
failure codes. I have also left out initialization methods.

I do not know if it matters, but I run both server and client on localhost.

There might be obvious errors, but I am quite new with OpenSSL.

Client code (inparams: hostname, certificate_chain_file,
ca_certificate_file):



SSL_library_init();
OpenSSL_add_all_algorithms();
SSL_load_error_strings();   
ERR_load_crypto_strings(); 
OpenSSL_add_all_ciphers();
SSL_METHOD const * method = SSLv23_method();  
SSL_CTX * ctx = SSL_CTX_new(method);
SSL_CTX_use_certificate_chain_file(ctx, certificate_chain_file));
const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 |
SSL_OP_NO_COMPRESSION; 
SSL_CTX_set_options(ctx, flags);
SSL_CTX_load_verify_locations(ctx, ca_certificate_file, NULL));
struct hostent * host = gethostbyname(hostname);
int client_sd = socket(PF_INET, SOCK_STREAM, 0);
struct sockaddr_in server;
memset(, 0, sizeof(server));
server.sin_family = AF_INET;
server.sin_port = htons(6789);
server.sin_addr.s_addr = *(long *) (host->h_addr);
connect(client_sd, (struct sockaddr *) , sizeof(server));
SSL * ssl = SSL_new(ctx);
SSL_set_fd(ssl, client_sd);
const char * const preferred_ciphers =
"HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4";
SSL_set_cipher_list(ssl, preferred_ciphers);  
SSL_set_tlsext_host_name(ssl, hostname);   
mydata_t mydata;
mydata_index_client = SSL_get_ex_new_index(0, (void *) "mydata index", NULL,
NULL, NULL);
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback_client);
SSL_CTX_set_verify_depth(ctx, 1);
mydata.verify_depth = 0;
SSL_set_ex_data(ssl, mydata_index_client, );
int connection_result = SSL_connect(ssl);
if (connection_result < 0)
{
  // Comes in here and ERR_get_error indicates
  // error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure
}
else if (connection_result == 0)
{
}
else if (connection_result == 1)
{
}
else
{
}



Server code (inparams: certificate_chain_file, ca_certificate_file):



SSL_library_init();
OpenSSL_add_all_algorithms();
SSL_load_error_strings();
SSL_METHOD const * method = SSLv23_method();
SSL_CTX * ctx = SSL_CTX_new(method);
SSL_CTX_use_certificate_chain_file(ctx, certificate_chain_file);  //Contains
only root CA
SSL_CTX_set_default_passwd_cb_userdata(ctx, (void *)
private_key_file_password);
SSL_CTX_set_default_passwd_cb(ctx, pem_passwd_cb);
SSL_CTX_load_verify_locations(ctx, ca_certificate_file, NULL);
struct sockaddr_in addr;
int server_sd = create_socket(addr, 6789);
bind(server_sd, (struct sockaddr *) , sizeof(addr));
listen(server_sd, max_nr_of_simultaneous_connections);
sockaddr_in client;
client.sin_family = AF_INET;
socklen_t c_len = sizeof(client);
int client_sd = accept(server_sd, (sockaddr *) , _len);
char remote_addr[INET_ADDRSTRLEN];
inet_ntop(client.sin_family, &(client.sin_addr), remote_addr,
INET_ADDRSTRLEN);
SSL * ssl = SSL_new(ctx);
SSL_set_fd(ssl, client_sd);
const char * const preferred_ciphers =
"HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4";
SSL_set_cipher_list(ssl, preferred_ciphers);   
STACK_OF(X509_NAME) * cert_names =
SSL_load_client_CA_file(certificate_chain_file);
if (cert_names != NULL)
{
SSL_CTX_set_client_CA_list(ctx, cert_names);
}
mydata_t mydata;
mydata_index_server = SSL_get_ex_new_index(0, (void *) "mydata index", NULL,
NULL, NULL);
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback_server);
SSL_CTX_set_verify_depth(ctx, 1);
mydata.verify_depth = 1;
SSL_set_ex_data(ssl, mydata_index_server, );
int accept_result = SSL_accept(ssl);
if (accept_result == 0)
{
}
else if (accept_result < 0)
{
  // Comes in here and ERR_get_error indicates
  // error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
}




openssl-ca.cnf:


HOME= .
RANDFILE= $ENV::HOME/.rnd


[ ca ]
default_ca  = CA_default# The default ca section


[ CA_default ]
default_days = 1000  # how long to certify for
default_crl_days = 30# how long before next CRL
default_md   = sha256# use public key default MD
preserve = no# keep passed DN ordering

x509_extensions  = ca_extensions # The extensions to add to the cert

email_in_dn  = no# Don't concat the email in the DN
copy_extensions  = copy  # Required to copy SANs from CSR to cert

base_dir= .
certificate = $base_dir/certs/ca_fromweb.cert.pem  # The CA certifcate
private_key = $base_dir/private/ca.key.pem   # The CA 

Re: [openssl-users] Can you suggest any technical name for changing sources from openssl-1.0.2 to openssl-1.1.0?

[Viktor Dukhovni]

> On Nov 29, 2016, at 10:12 AM, Jakob Bohm  wrote:
> 
>> /*
>>  * OPENSSL_VERSION_NUMBER(3):
>>  *
>>  * OPENSSL_VERSION_NUMBER is a numeric release version identifier:
>>  *
>>  * MMNNFFPPS: major minor fix patch status
>>  *
> 
> Shouldn't this be
> MNNFFPPS: major minor fix patch status (only 1 nibble for major)

Yes, the comment in that file has an extra nibble for the major number,
but for portability reasons the version number is only 32 bits.

The code below the comment parses the unsigned long version number as
follows:

if (version < 0x0930) {
info->status = 0;
info->patch = version & 0x0f;
version >>= 4;
info->micro = version & 0x0f;
version >>= 4;
info->minor = version & 0x0f;
version >>= 4;
info->major = version & 0x0f;
} else if (version < 0x00905800L) {
info->patch = version & 0xff;
version >>= 8;
info->status = version & 0xf;
version >>= 4;
info->micro = version & 0xff;
version >>= 8;
info->minor = version & 0xff;
version >>= 8;
info->major = version & 0xff;
} else {
info->status = version & 0xf;
version >>= 4;
info->patch = version & 0xff;
version >>= 8;
info->micro = version & 0xff;
version >>= 8;
info->minor = version & 0xff;
version >>= 8;
info->major = version & 0xff;
if (version < 0x00906000L)
info->patch &= ~0x80;
}

So it could produce a major version > 15 on systems where long
is > 32 bits, but that's unlikely on the OpenSSL side at present.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to produce a nested CMS / PKCS#7 structure?

[Dr. Stephen Henson]

On Mon, Nov 28, 2016, Wim Lewis wrote:

> 
> However, I think the other half of my problem remains: if I'm putting
> another CMS object into a SignedData, AuthEnvelopedData, or other kind of
> wrapper, the OCTET STRING should contain the encoding of that object's
> structure (e.g. a BER-encoded AuthEnvelopedData, SignedData,
> ContentWithAttributes, etc. structure), not a ContentInfo *containing* that
> structure, right? How do I get OpenSSL to give me that encoded object
> without an enclosing ContentInfo?
> 

It's my understanding that the content should be a ContentInfo but I can't see
a definitive reference to this.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Can you suggest any technical name for changing sources from openssl-1.0.2 to openssl-1.1.0?

[Jakob Bohm]

On 28/11/2016 21:50, Viktor Dukhovni wrote:

On Nov 28, 2016, at 3:40 PM, Salz, Rich  wrote:

Perhaps I didn't understand the original question.  If all you want to do is 
compare 1.0.2 and 1.1.0, then look at OPENSSL_VERSION_NUMBER; if defined at 
it's 0x10101000L or greater, then you;'re on the 1.1.x branch, otherwise you 
are not and therefore on 1.0.2 or earlier.

The OPENSSL_VERSION_NUMBER macro dates back to some of the earliest
OpenSSL releases, and is therefore always defined.  Postfix has the
following comment in src/tls/tls_misc.c which covers the relevant
history:

 /*
  * OPENSSL_VERSION_NUMBER(3):
  *
  * OPENSSL_VERSION_NUMBER is a numeric release version identifier:
  *
  * MMNNFFPPS: major minor fix patch status
  *

Shouldn't this be
MNNFFPPS: major minor fix patch status (only 1 nibble for major)


  * The status nibble has one of the values 0 for development, 1 to e for
  * betas 1 to 14, and f for release. Parsed OpenSSL version number. for
  * example
  *
  * 0x000906000 == 0.9.6 dev 0x000906023 == 0.9.6b beta 3 0x00090605f ==
  * 0.9.6e release
  *
  * Versions prior to 0.9.3 have identifiers < 0x0930.  Versions between
  * 0.9.3 and 0.9.5 had a version identifier with this interpretation:
  *
  * MMNNFFRBB major minor fix final beta/patch
  *
  * for example
  *
  * 0x000904100 == 0.9.4 release 0x000905000 == 0.9.5 dev
  *
  * Version 0.9.5a had an interim interpretation that is like the current
  * one, except the patch level got the highest bit set, to keep continu-
  * ity.  The number was therefore 0x0090581f.
  */





Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Disabling Client-Initiated TLS renegotiation

[Wall, Stephen]

I suppose one could abuse SSL_set_msg_callback() to create a filter that 
rewrites the initial re-handshake message into something innocuous.  Though I 
doubt that would work, once the client starts a handshake, it expects a 
response from the server, and may well time out and close if it does not get 
one.  The way TLS works, it is always the client starting a renegotiation.  The 
server can send a message asking the client to renegotiate, but the client can 
ignore that. I don't believe the opposite is true.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Sashank Mullapudi (samullap)
Sent: Monday, November 28, 2016 10:56 PM
To: openssl-users@openssl.org
Cc: Ram Mohan R (rmohanr) ; Nikhil Mittal (nimittal) 
; Anil Kumar (anilkum) 
Subject: Re: [openssl-users] Disabling Client-Initiated TLS renegotiation

Resending this hoping for a response from someone who has information on 
disabling TLS renegotiation from the Client side.

Thanks,
Sashank

From: samullap >
Date: Tuesday, 22 November 2016 at 12:21 PM
To: "openssl-users@openssl.org" 
>
Cc: "Ram Mohan R (rmohanr)" >, 
"Anil Kumar (anilkum)" >, "Nikhil 
Mittal (nimittal)" >
Subject: Disabling Client-Initiated TLS renegotiation

Hi,

As part of securing our web interfaces, we wanted to disable client-initiated 
TLS renegotiation.

The reasoning for this requirement is as follows- Generally, renegotiation of 
TLS sessions is much more resource-intensive for the server than the client, 
and should therefore not be performed at will to avoid degrading performance. 
Disabling client from renegotiating secures the server from undergoing a DoS 
attack due to continuous renegotiation requests.

I see that there is an option SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION, but 
that is to secure the renegotiation, not disable it.

I wanted to check if there is a patch or flag available to disable any 
negotiation initiated from the client side.

Thanks and Regards,
Sashank
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users