Re: [openssl-users] Unable to select NULL or NULL-MD5

[Viktor Dukhovni]

> On Mar 28, 2018, at 7:14 PM, Eric Jacksch  wrote:
> 
> I'm using OpenSSL for testing and recently compiled 1.1.0g and h. I'm seeing 
> the same behaviour in both. 
> 
> openssl ciphers -v list the NULL ciphers, but when I try to use NULL or 
> NULL-MD5 I get the same result:  No ciphers available.
> 
> I've tried several compile options to no avail.

To use eNULL ciphers you must set the security level to 0:

$ openssl ciphers -s -tls1_2 -v eNULL:@SECLEVEL=0
ECDHE-ECDSA-NULL-SHATLSv1 Kx=ECDH Au=ECDSA Enc=None  Mac=SHA1
ECDHE-RSA-NULL-SHA  TLSv1 Kx=ECDH Au=RSA  Enc=None  Mac=SHA1
AECDH-NULL-SHA  TLSv1 Kx=ECDH Au=None Enc=None  Mac=SHA1
NULL-SHA256 TLSv1.2 Kx=RSA  Au=RSA  Enc=None  Mac=SHA256
NULL-SHASSLv3 Kx=RSA  Au=RSA  Enc=None  Mac=SHA1
NULL-MD5SSLv3 Kx=RSA  Au=RSA  Enc=None  Mac=MD5

-- 
Viktor.

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

Re: [openssl-users] get type of PEM data

[Jordan Brown]

Thanks, all.

Michael:  Yeah, that was my fallback idea, but I really didn't want my
application to have to know about every "---BEGIN" line for every type
of private key.  (And similarly if there's more than one kind of
certificate, but I don't think there is.)
Viktor, Richard:  PEM_read_bio certainly helps, avoids the chore
associated with discarding leading noise, but as above I was hoping to
not need to know about every type of private key.
Matt:  Indeed, looks very promising.  Now if only we were on 1.1.1 :-(. 
I'm a little surprised that it doesn't read from a BIO.

So, net, there's stuff in 1.0.x that will help and stuff in 1.1.x that
will likely do exactly what I need.  That answers my question, thanks!

-- 
Jordan Brown, Oracle Solaris

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

Re: [openssl-users] Unable to select NULL or NULL-MD5

[Salz, Rich via openssl-users]

>openssl ciphers -v list the NULL ciphers, but when I try to use NULL or 
>NULL-MD5 I get the same result:  No ciphers available.

You have to configure with a cipher string that has “@SECLEVEL=0” in it.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Unable to select NULL or NULL-MD5

[Matt Caswell]

On 29/03/18 00:14, Eric Jacksch wrote:
> Greetings,
> 
> I'm using OpenSSL for testing and recently compiled 1.1.0g and h. I'm
> seeing the same behaviour in both. 
> 
> openssl ciphers -v list the NULL ciphers, but when I try to use NULL or
> NULL-MD5 I get the same result:  No ciphers available.
> 
> I've tried several compile options to no avail.
> 
> Can anyone point me in the right direction?
> 
> Thanks!
> 
> 
> ./openssl s_client -connect x.x.x.x:443 -cipher NULL

Change you cipher list to be `-cipher NULL:@SECLEVEL=0`. If your server
is also running OpenSSL then you'll need to enable it there as well.

The default security level is 1, which disables NULL ciphers amongst
various other things.

Matt





> 
> CONNECTED(0003)
> 
> 140735917126464:error:141640B5:SSL
> routines:tls_construct_client_hello:no ciphers
> available:ssl/statem/statem_clnt.c:800:
> 
> ---
> 
> no peer certificate available
> 
> ---
> 
> No client certificate CA names sent
> 
> ---
> 
> SSL handshake has read 0 bytes and written 0 bytes
> 
> Verification: OK
> 
> ---
> 
> New, (NONE), Cipher is (NONE)
> 
> Secure Renegotiation IS NOT supported
> 
> Compression: NONE
> 
> Expansion: NONE
> 
> No ALPN negotiated
> 
> SSL-Session:
> 
>     Protocol  : TLSv1.2
> 
>     Cipher    : 
> 
>     Session-ID: 
> 
>     Session-ID-ctx: 
> 
>     Master-Key: 
> 
>     PSK identity: None
> 
>     PSK identity hint: None
> 
>     SRP username: None
> 
>     Start Time: 1522278574
> 
>     Timeout   : 7200 (sec)
> 
>     Verify return code: 0 (ok)
> 
>     Extended master secret: no
> 
> ---
> 
> -- 
> Eric Jacksch, CPP, CISM, CISSP
> +1 613 482-7650
> e...@jacksch.com 
> Twitter: @EricJacksch
> https://SecurityShelf.com 
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Unable to select NULL or NULL-MD5

[Eric Jacksch]

Greetings,

I'm using OpenSSL for testing and recently compiled 1.1.0g and h. I'm
seeing the same behaviour in both.

openssl ciphers -v list the NULL ciphers, but when I try to use NULL or
NULL-MD5 I get the same result:  No ciphers available.

I've tried several compile options to no avail.

Can anyone point me in the right direction?

Thanks!


./openssl s_client -connect x.x.x.x:443 -cipher NULL

CONNECTED(0003)

140735917126464:error:141640B5:SSL routines:tls_construct_client_hello:no
ciphers available:ssl/statem/statem_clnt.c:800:

---

no peer certificate available

---

No client certificate CA names sent

---

SSL handshake has read 0 bytes and written 0 bytes

Verification: OK

---

New, (NONE), Cipher is (NONE)

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE

No ALPN negotiated

SSL-Session:

Protocol  : TLSv1.2

Cipher: 

Session-ID:

Session-ID-ctx:

Master-Key:

PSK identity: None

PSK identity hint: None

SRP username: None

Start Time: 1522278574

Timeout   : 7200 (sec)

Verify return code: 0 (ok)

Extended master secret: no

---
-- 
Eric Jacksch, CPP, CISM, CISSP
+1 613 482-7650
e...@jacksch.com
Twitter: @EricJacksch
https://SecurityShelf.com 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] get type of PEM data

[Richard Levitte]

In message  on Wed, 
28 Mar 2018 08:02:37 -0700, Jordan Brown  said:

openssl> I'm finding that it would be helpful to have a function that
openssl> would, given PEM data (in memory or in a file) return an
openssl> indication of what kind of object it represents: a
openssl> certificate, a private key, et cetera. The ideal function
openssl> would basically tell me which PEM_read_bio_foobar function I
openssl> would use to read the PEM data (and thus what C type it
openssl> represents). It would lump all private key formats into one
openssl> type, since PEM_read_PrivateKey would work on all of them and
openssl> return an EVP_PKEY. 
openssl> 
openssl> Does such a function already exist? Any thoughts?

PEM_read and PEM_read_bio should do what you want.  You need to
provide three buffers, |name|, |header| and |data|.  |name| will
contain the name from the -BEGIN line, that string describes the
type of data you have in |data|.

I suggest you read the manual on these functions, there are a few
things you need to do to decode something that's encrypted, for
example.

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

Re: [openssl-users] get type of PEM data

[Matt Caswell]

Take a look at the new STORE functions in 1.1.1. They do something like
what you are describing. They can take a URI and load whatever objects
it finds there using the right kind of loader based on the PEM type. You
can also search for particular objects in your store. See:

https://www.openssl.org/docs/man1.1.1/man3/OSSL_STORE_load.html
https://www.openssl.org/docs/man1.1.1/man3/OSSL_STORE_INFO.html
https://www.openssl.org/docs/man1.1.1/man3/OSSL_STORE_SEARCH.html

Matt


On 28/03/18 16:02, Jordan Brown wrote:
> I'm finding that it would be helpful to have a function that would,
> given PEM data (in memory or in a file) return an indication of what
> kind of object it represents:  a certificate, a private key, et cetera. 
> The ideal function would basically tell me which PEM_read_bio_foobar
> function I would use to read the PEM data (and thus what C type it
> represents).  It would lump all private key formats into one type, since
> PEM_read_PrivateKey would work on all of them and return an EVP_PKEY.
> 
> Does such a function already exist?  Any thoughts?
> 
> -- 
> Jordan Brown, Oracle Solaris
> 
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RFC5077 ticket construction help

[Michael Richardson]

Henderson, Karl via openssl-users  wrote:
> A wants to talk to B
> A and B have a relationship with C
> C constructs an RFC5077 ticket and gives it to A so that A can contact B

> Are there any good examples of how to do this?

Aside Viktor's comment, this is also classic OAUTH2 situation.

But, it sounds like you need to do this below the application layer
in the TLS layer.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

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

Re: [openssl-users] RFC5077 ticket construction help

[Henderson, Karl via openssl-users]

In this use case, I may want to have yet another client D that wants to talk to 
B using the same session ticket. This way, B doesn't need to keep a cert per 
client. This may pose some security risks but at this point, I'm just trying to 
make it work.

On 3/28/18, 1:50 PM, "Viktor Dukhovni"  wrote:

issuing client certs


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RFC5077 ticket construction help

[Viktor Dukhovni]

> On Mar 28, 2018, at 1:37 PM, Henderson, Karl via openssl-users 
>  wrote:
> 
> Ok, but I’d like to use TLS rather than Kerberos. I’m wondering if I could do 
> something like this:
>  
>   • C sends a Client Hello with 0 length Session Ticket to B.
>   • B sends back a NewSessionTicket to C in Server Hello.
>   • C sets SSL_CTX_sess_set_new_cb(ctx, new_session_cb) and saves the 
> session blob/ticket in the new_session_cb function indexed by the URL of B.
>   • A contacts C with the URL of B
>   • C looks up session ticket indexed by URL of B
>   • C sends A the session ticket.
>   • A contact B and sets the ticket using SSL_set_session_ticket_ext(ssl, 
> ticket, ticket size)
>  
> Feasible? I’m trying something like this now but I can’t get it working.

This is essentially what happens in Postfix much of the time between the 
tlsmgr(8)
process which manages the TLS session cache and the smtp(8) delivery agent which
talks TLS to remote servers, except the initial acquisition of the session is
by a delivery agent that did not find a session to re-use or tried to re-use a
session, but the server did a full handshake anyway...

Which brings us to an important point.  The server might not resume
a session for any number of reasons, and will do a full handshake.
Then what?  Session resumption is an optimization, and the server
can choose to ignore the presented ticket, or might decide it is
too stale, or that the phase of the moon is wrong, and not use it.

Secondly, you need a very secure channel between C and A, as the
serialized session, may allow off-line decryption of subsequent
traffic between A and C, or at least a man-in-the-middle attack.
The master secret for the cached connection is part of that data.

What's wrong with issuing client certs trusted by B?

-- 
-- 
Viktor.

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

Re: [openssl-users] RFC5077 ticket construction help

[Henderson, Karl via openssl-users]

Ok, but I’d like to use TLS rather than Kerberos. I’m wondering if I could do 
something like this:

 
C sends a Client Hello with 0 length Session Ticket to B.
B sends back a NewSessionTicket to C in Server Hello.
C sets SSL_CTX_sess_set_new_cb(ctx, new_session_cb) and saves the session 
blob/ticket in the new_session_cb function indexed by the URL of B.
A contacts C with the URL of B
C looks up session ticket indexed by URL of B
C sends A the session ticket.
A contact B and sets the ticket using SSL_set_session_ticket_ext(ssl, ticket, 
ticket size)
 

Feasible? I’m trying something like this now but I can’t get it working. 

 

From: openssl-users  on behalf of Michael 
Sierchio 
Reply-To: "openssl-users@openssl.org" 
Date: Wednesday, March 28, 2018 at 12:45 PM
To: "openssl-users@openssl.org" 
Subject: [EXTERNAL] Re: [openssl-users] RFC5077 ticket construction help

 

 

Since there exists a reference implementation, and the source code is 
available, why not start there?  The symmetric key protocol is the basis of 
Kerberos.

 

- M

 

On Wed, Mar 28, 2018 at 9:26 AM, Henderson, Karl via openssl-users 
 wrote:

Need some help with RFC5077 ticket construction. I’d like to implement a type 
of Needham-Schroeder protocol where:

 
A wants to talk to B
A and B have a relationship with C
C constructs an RFC5077 ticket and gives it to A so that A can contact B
 

Are there any good examples of how to do this?

 

The problem I think I’m having the most difficulty with is understanding what I 
need to put into the encrypted_state portion of the session ticket.

 

Thanks,

Karl

 


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



 

-- 

"Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, 
but an intelligent person requires only two thousand five hundred." 


- The Mahābhārata



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] get type of PEM data

[Viktor Dukhovni]

> On Mar 28, 2018, at 11:02 AM, Jordan Brown  
> wrote:
> 
> I'm finding that it would be helpful to have a function that would, given PEM 
> data (in memory or in a file) return an indication of what kind of object it 
> represents:  a certificate, a private key, et cetera.  The ideal function 
> would basically tell me which PEM_read_bio_foobar function I would use to 
> read the PEM data (and thus what C type it represents).  It would lump all 
> private key formats into one type, since PEM_read_PrivateKey would work on 
> all of them and return an EVP_PKEY.
> 
> Does such a function already exist?  Any thoughts?

PEM_read_bio() reads a generic PEM object.  The header name
can then be compared with the various PEM_STRING_... constants.

OpenSSL can already read keys in a general way.  See, 
PEM_read_bio_PrivateKey() returning an EVP_PKEY.  So you
don't need to reinvent this.

-- 
Viktor.

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

Re: [openssl-users] RFC5077 ticket construction help

[Viktor Dukhovni]

> On Mar 28, 2018, at 12:46 PM, Michael Sierchio  wrote:
> 
> It would make more sense, but you're changing the problem definition. 
> Needham-Schroeder is intended to be used over an insecure network.

I'm guessing that C's purpose is issuance of client credentials.
If the requirement is to avoid PKI, then TLS is not the protocol
one wants to use.  Use GSSAPI, say via libknc:

https://github.com/elric1/knc/tree/master/lib

-- 
Viktor.

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

Re: [openssl-users] RFC5077 ticket construction help

[Michael Sierchio]

On Wed, Mar 28, 2018 at 9:44 AM, Viktor Dukhovni  wrote:

It would more sense for C to issue short-term client certificates.
> Session tickets are for session resumption.  In particular they
> can't authenticate the server to the client, so you still need
> an initial handshake for that.
>
> To do GSSAPI with TLS, do TLS on the outside (client authenticates
> the server and establishes an secure channel), and then GSSAPI
> with channel binding (server authenticates the client as being the
> party at the other end of the channel).
>
>
It would make more sense, but you're changing the problem definition.
Needham-Schroeder is intended to be used over an insecure network.


-- 
"Well," Brahma said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five hundred."

- The Mahābhārata
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RFC5077 ticket construction help

[Salz, Rich via openssl-users]

  *   Need some help with RFC5077 ticket construction. I’d like to implement a 
type of Needham-Schroeder protocol where:


That’s not what TLS tickets are for.  It is for having session state, where the 
client holds all the state and the server (having only the decryption key) can 
resume the connection.

You might want to look at OAUTH and the “TLS exporter” documents.

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

Re: [openssl-users] RFC5077 ticket construction help

[Michael Sierchio]

Since there exists a reference implementation, and the source code is
available, why not start there?  The symmetric key protocol is the basis of
Kerberos.

- M

On Wed, Mar 28, 2018 at 9:26 AM, Henderson, Karl via openssl-users <
openssl-users@openssl.org> wrote:

> Need some help with RFC5077 ticket construction. I’d like to implement a
> type of Needham-Schroeder protocol where:
>
>
>
>- A wants to talk to B
>- A and B have a relationship with C
>- C constructs an RFC5077 ticket and gives it to A so that A can
>contact B
>
>
>
> Are there any good examples of how to do this?
>
>
>
> The problem I think I’m having the most difficulty with is understanding
> what I need to put into the encrypted_state portion of the session ticket.
>
>
>
> Thanks,
>
> Karl
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
"Well," Brahma said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five hundred."

- The Mahābhārata
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RFC5077 ticket construction help

[Viktor Dukhovni]

> On Mar 28, 2018, at 12:26 PM, Henderson, Karl via openssl-users 
>  wrote:
> 
> Need some help with RFC5077 ticket construction. I’d like to implement a type 
> of Needham-Schroeder protocol where:
>  
>   • A wants to talk to B
>   • A and B have a relationship with C
>   • C constructs an RFC5077 ticket and gives it to A so that A can 
> contact B
>  
> Are there any good examples of how to do this?
>  
> The problem I think I’m having the most difficulty with is understanding what 
> I need to put into the encrypted_state portion of the session ticket.

It would more sense for C to issue short-term client certificates.
Session tickets are for session resumption.  In particular they
can't authenticate the server to the client, so you still need
an initial handshake for that.

To do GSSAPI with TLS, do TLS on the outside (client authenticates
the server and establishes an secure channel), and then GSSAPI
with channel binding (server authenticates the client as being the
party at the other end of the channel).

-- 
Viktor.

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

[openssl-users] RFC5077 ticket construction help

[Henderson, Karl via openssl-users]

Need some help with RFC5077 ticket construction. I’d like to implement a type 
of Needham-Schroeder protocol where:

 
A wants to talk to B
A and B have a relationship with C
C constructs an RFC5077 ticket and gives it to A so that A can contact B
 

Are there any good examples of how to do this?

 

The problem I think I’m having the most difficulty with is understanding what I 
need to put into the encrypted_state portion of the session ticket.

 

Thanks,

Karl

 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] get type of PEM data

[Michael Wojcik]

enum pem_type {
PEM_TYPE_NONE = 0,
PEM_TYPE_CERTIFICATE,
PEM_TYPE_RSA_PRIVATE
};

struct pem_map {
enum pem_type type;
const char *pem_string;
};

#include 

enum pem_type identify_pem(const char *pem) {
static const struct pem_map map[] = {
{ PEM_TYPE_CERTIFICATE, PEM_STRING_X509 "-" },
{ PEM_TYPE_RSA_PRIVATE, PEM_STRING_RSA "-" },
};
const char *pem_begin;
int idx;

if (!pem) return PEM_TYPE_NONE;

if (! (pem_begin = strstr(pem, "-BEGIN "))) return PEM_TYPE_NONE;
pem_begin += 11;

for (idx = 0; idx < sizeof map / sizeof *map; idx++) {
if (strncmp(pem_begin, map[idx].pem_string, 
strlen(map[idx].pem_string)) == 0) {
return map[idx].type;
}
}

return PEM_TYPE_NONE;
}

Untested. Extending to the remainder of the PEM types (see pem.h) is left as an 
exercise for the reader.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




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

[openssl-users] get type of PEM data

[Jordan Brown]

I'm finding that it would be helpful to have a function that would,
given PEM data (in memory or in a file) return an indication of what
kind of object it represents:  a certificate, a private key, et cetera. 
The ideal function would basically tell me which PEM_read_bio_foobar
function I would use to read the PEM data (and thus what C type it
represents).  It would lump all private key formats into one type, since
PEM_read_PrivateKey would work on all of them and return an EVP_PKEY.

Does such a function already exist?  Any thoughts?

-- 
Jordan Brown, Oracle Solaris

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