> 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 availab
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 certa
>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
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
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
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 k
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
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 sit
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" wro
> 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
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/tick
> 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
> 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 avoi
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
* 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 con
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 tic
> 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 const
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?
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[] = {
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
20 matches
Mail list logo
