gmane.comp.encryption.openssl.devel

RE: Question on expiring certs on long-lived DTLS sessions

Dave Thompson — 2013-05-22T23:22:16

I don't think this is a -dev question, but not worth changing.


*certificate* lifecycle (approval, issuance, expiration, revocation, 
distribution, etc.) is external to SSL/TLS.

*session* lifecycle is kind of implicit in the TLS RFCs 
but I don't recall seeing any separate doc on it.

You need to to distinguish here between "context" (internal to 
openssl), "session" and "connection" which are not the same.


When a *session* is set up, yes. You normally create a (new) 
SSL/TLS connection by doing a full handshake which among other 
things validates the cert and creates a session; the session 
is basically the master-secret and authentication info.
You can then create additional connections using the same 
session, commonly called "resumption", if both endpoints 
(server and client) support it; openssl server does within 
a process by itself, and cross-process with some assistance;
openssl client does only with some application help.
Conversely and applicable to your question, you can create a 
new session on an existing connection, called "renegotiation",
again if both endpoints support it. Most do, but during the 
Apache-prefix vulnerability and exploit in late 2009, some 
implementations (including IIRC 1 or 2 versions of openssl) 
and many systems and people turned off renegotiation entirely 
as a sledgehammer fix. There is now a better fix (RFC 5746) 
but unless both/all the endpoints are under your control 
you may encounter some that don't support or deploy it.


Those are really two or three different questions.

To check if the peer cert expires (or is revoked) during a 
session you can either reverify yourself (for expiration 
you can just get the notAfter time and check it, but for 
revocation you need to get a fresh CRL or OCSP or similar), 
or you can direct openssl to renegotiate (explicitly, or 
if you use ssl-BIO by setting time and/or data limits).

To change your "own" cert and key (the one the server uses 
to authenticate to the client, or the client uses if you 
use client authentication) your code must re-call 
_usePrivateKey and _useCertificate or _use...Chain.
This will be needed if/before your cert has expired or 
been revoked and you want to start a new session.

If a peer cert expires (or is revoked) but the peer gets 
a new cert under a CA root that remains valid, openssl will 
aceept that under the existing truststore. Most public CAs 
have root periods of decades precisely to allow this.
If a peer replaces an expired selfsigned cert, or gets 
a new cert under a CA root that is not already trusted:

- if you used _load_verify_loc...(,file,), equivalent to 
-CAfile on some openssl commandline (and possibly other apps),
your code must re-call to re-read the file.

- if you used _load_verify_loc...(,,dir), equivalent to 
-CApath, you can just put the new cert in there, *with* 
the correct hashlink or (on Windows) hashname, and it 
will be found dynamically when verification is next done.

- if you used both file and dir, it depends on where you 
put the new cert(s)

- if you used _default_verify_paths and the default file 
and/or dir exist, ditto


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev< at >openssl.org
Automated List Manager                           majordomo< at >openssl.org

Re: [openssl.org #3052] [PATCH] OpenSSL 1.0.1e bug fix for x86_64-gf2m.pl use of STDOUT

Phillip Hellewell via RT — 2013-05-22T14:08:02

Looks like this goes with bug #2963 ("Windows build bug (perl/nasm
race) on OpenSSL 1.0.0c").

Other .pl files were fixed, but this one was somehow missed.

Phillip

On Tue, May 21, 2013 at 11:00 AM, Phillip Hellewell <sshock< at >gmail.com> wrote:

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev< at >openssl.org
Automated List Manager                           majordomo< at >openssl.org

[openssl.org #3052] [PATCH] OpenSSL 1.0.1e bug fix for x86_64-gf2m.pl use of STDOUT

Phillip Hellewell via RT — 2013-05-22T14:06:28

My build script was failing to generate x86_64-gfm2.obj, both when
using masn and nasm.

Unlike all the other x86_64*.pl files, it was opening STDOUT directly,
so I changed it to work like the others and that fixed the problem.

Please apply this patch.

Thanks,
Phillip Hellewell

[openssl.org #3051] [PATCH] Build fixes for 8a97a330

Adam Langley via RT — 2013-05-22T14:05:56

This patch fixes a couple of minor build issues on the current master
branch (8a97a330).

[openssl.org #3050] x509 PEM certificate input parsing bug

Casey McGinty via RT — 2013-05-22T14:05:34

I hit a bug when inputting an x509 certificate into openssl. My CA is
Entrust.net, and they have some certificates for download that have no line
endings in the encoding. This causes openssl parser to fail when it tries
to read the certificate, even thought the certificate is valid. Here is the
response from Entrust.net:

I checked into this formatting question some more for you.  The Certificate

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev< at >openssl.org
Automated List Manager                           majordomo< at >openssl.org

Question on expiring certs on long-lived DTLS sessions

Paul Pazandak — 2013-05-21T19:53:22


We want to be able to handle long-lived connections/sessions, and we are therefore wondering about situations where a client or server certificate may expire either 1)after we have established a context, or 2)after a session has started.  Perhaps the first question is: how often is a certificate validated?


Do we have to programmatically manage this situation (dealing with expiring certs & adding new certs) within our app, or is it possible to point to a cert store that we can then update with a new cert via the openSSL command line tool?

Thanks.

Question on expiring certs on long-lived DTLS sessions

Paul Pazandak — 2013-05-22T01:57:49

All,

We want to be able to handle long-lived connections/sessions, and we are therefore wondering about situations where a client or server certificate may expire either 1)after we have established a context, or 2)after a session has started.  Perhaps the first question is: how often is a certificate validated?
[if there are docs that describe the certificate lifecycle (I couldn't find them), pls point us to them!]

From an initial digging into the code, it appears that the certificate is only validated before a session is set up.  So, if a cert expires after this, it will never be detected as long as the session is running.  Is this true?

Do we have to programmatically manage expiring certs (dealing with expiring certs & adding new certs) within our app, or is it possible to point to a cert store that we can then update external to the app (e.g. with a new cert via the openSSL command line tool) and then have the openSSL lib manage it?

Thanks!

Paul

Running OpenSSL test suite against custom crypto engine?

JT Olds — 2013-05-21T22:31:06

Hey,

When 'make test' is invoked, a huge suite of tests is run against OpenSSL.
I have a custom OpenSSL engine (this one:
http://rt.openssl.org/Ticket/Display.html?id=2554 ), and I'm looking for
bugs in the whole stack (the hardware, the engine, etc).

Is there a way to run the test suite against a specific engine?

Thanks
-JT

Re: Smart card support with Openssl

Douglas E. Engert — 2013-05-21T19:37:58


On 5/18/2013 2:09 PM, Rajeswari K wrote:

Have a look at
https://www.opensc-project.org/opensc/wiki/engine_pkcs11

This is an engine that can call pkcs11, either the OpenSC
or some other PKCS#11 implementation.

Cipher sorting: ssl_cipher_apply_rule() never processes list with one member?

Peter Sandelin — 2013-05-21T07:51:00

Hi,
while debugging I discovered what I think is a bug in
the CIPHER list handling ssl_cipher_apply_rule().
I think it does not work for a list of size one.

OpenSSL version 1.0.1c.
ssl_ciph.c: 956
Function: ssl_cipher_apply_rule
951:        curr = head;
950:        last = tail;
......
954:   for (;;)
955:   {
956:     if ((curr == NULL) || (curr == last)) break;

The break criteria "(curr == last) is strange.
I arrive here with only ONE member in my list, so
-> head == tail  -> curr == last.
So it breaks the for loop directly and does not process the rule below.

I think the problem is specific for a list of one member.
Can someone please help to confirm if this is a bug or not?

Best regards
Peter
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev< at >openssl.org
Automated List Manager                           majordomo< at >openssl.org

Re: [PATCH][RFC] CPU Jitter random number generator

Stephan Mueller — 2013-05-21T16:36:47

On Tue, 21 May 2013 12:04:13 +0200
Andy Polyakov <appro< at >openssl.org> wrote:

Hi Andy,


Unfortuately I am not an assembler wizzard, but I guess you only try to
return parts of the rdtsc instruction?

Without optimization:

$ gcc -o test test.c
$ ./test > test.out
cat test.out | wc
 128886  128886  386814

Test with optimizations:

$ gcc -O2 -o test test.c
./test > test.out
$ cat test.out | wc
 270876  270876  812741

So, where is the problem?

This is performed on

$ cat /proc/cpuinfo | grep CPU
model name      : Intel(R) Core(TM) i7-2620M CPU < at > 2.70GHz


All values I see fluctuate according to the values in the graph in
chapter 2.

By any chance, did you disable your TSC (you could do that on a
per-process basis)?

Bottom line, with the code you suggest, I still see the same
fluctuations I used to draw the graphs in chapter 2. Note, this is just
a visual inspection of the values I see in test.out.


Very interesting that you have a different reaction on your system.

All tests I did so far on different CPUs show the expected results.

Can you tell me more about your system? Can you please execute
jent_entropy_init() all by itself?


All your system shows implies that the root cause is not present.
Hence, the code requires to execute jent_entropy_init() and only
continue when this function returns without an error.

That function shall check whether you underlying system shows the
expected functionality.

Observing the memory accesses is not the intention.


Thanks
Stephan

Re: [PATCH][RFC] CPU Jitter random number generator

Andy Polyakov — 2013-05-21T10:04:13

Hi,


Consider following snippet:

static inline unsigned int rdtsc()
{ int eax;
        asm volatile("rdtsc":"=a"(eax)::"edx");
  return eax;
}
main()
{ int i;
  unsigned int diff1, diff0 = rdtsc() - rdtsc();

     for (i=0;i<10000000;i++)
        if ((diff1 = rdtsc() - rdtsc()) != diff0)
                printf("%u\n",-diff0), diff0=diff1;
}

How many lines do you think it would print? If I compile it with
optimization on, my Sandy Bridge system prints ... ~100 lines. Hundred
out of 10 million tries. Of the hundred half of values is 28 and half is
thousands and up, obviously timer interrupts. Thousands and up is
something you suggest to disregard, so all we have is single value of
28. What "miniscule variations" of which "instruction" are we talking
about? What I'm trying to say is that I can't see that you managed to
actually formulate what is "the root cause of entropy". "CPU execution
time jitter" does not describe it. I'd argue that variations originate
from interactions with memory subsystem. You use call to function and on
x86 it involves writing return address to stack and fetching it at
return [as well as reading system timer value from memory in user-land
case involves memory reference]. What I'm also trying to say is that the
phenomena has to be platform-specific [as there are platforms where call
to subroutine does not involve reference to memory]. Even with [plain]
references to memory there is no guarantee that samples won't form
regular pattern on some platform or under some circumstances such as
really idle system and everything is in cache. On the contrary, it was
observed to form regular pattern. The fact that it allegedly didn't on
*your* system is not sufficient. One should also keep in mind that on
some platforms timer counter is fed with alternative frequency and any
variations that are less than former simply can't be measured. Example
of such platform is PPC, where counter runs at frequencies several times
lower than processor operating frequency. One of extreme cases is factor
of 81 on PowerBook G4. Equivalent of above program for PPC prints
sequence of 0 and 1 (and occasional timer interrupts), where 1s indicate
transition to next counter value.

If you ought to capture variations in interaction with memory subsystem,
you ought to ensure that there are memory references between timer
readings. References preferably should be non-trivial, as slow as
possible and involve as many components as possible, yet have as little
OS dependencies as possible. This is what
http://www.openssl.org/~appro/OPENSSL_instrument_bus/ is about. See even
http://marc.info/?t=132655907800004&r=1&w=2.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev< at >openssl.org
Automated List Manager                           majordomo< at >openssl.org

RE: [openssl.org #2886] AutoReply: openssl cms cmsout serial number output format

Jon Lusky via RT — 2013-05-19T14:43:38

ping

-----Original Message-----
From: The default queue via RT [mailto:rt< at >openssl.org] 
Sent: Monday, October 01, 2012 9:29 AM
To: lusky< at >blown.net
Subject: [openssl.org #2886] AutoReply: openssl cms cmsout serial number output format 


Greetings,

This message has been automatically generated in response to the creation of a trouble ticket regarding:
"openssl cms cmsout serial number output format", a summary of which appears below.

There is no need to reply to this message right now.  Your ticket has been assigned an ID of [openssl.org #2886].

Please include the string:

         [openssl.org #2886]

in the subject line of all future correspondence about this issue. To do so, you may reply to this message.

                        Thank you,
                        rt< at >openssl.org

-------------------------------------------------------------------------
The serial number output for in cmsout is inconsistent with the format displayed by openssl x509 -text.  cmsout always displays an integer, whereas
x509 -text will display a hex representation of very large ints.  For troubleshooting S/MIME email encryption problems, it's extremely helpful to have these in the same format.  Attached is a patch to change the format of the cmsout output.  It probably has side effects and needs to be completely redone, but it'll give you an idea.

 

 

 

 

 



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev< at >openssl.org
Automated List Manager                           majordomo< at >openssl.org

Smart card support with Openssl

Rajeswari K — 2013-05-18T19:09:45

Hello Users/dev Team,

Need some urgent help to program openssl for smart card/HSM.

Our smart card never shares private keys. All crypto operations such as
encryption,decryption will be performed by smart card. And any such actions
from openssl needs to be redirected to smart card. Only certicate is left
open.

Have read about pkcs11 crypto engine support at openssl. Currently we are
using openssl 0.9.8q. Does this version supports pkcs11 engine support?
If supports, can you provide which part of the code needs to be changed to
have successful handshake using smart card.

Currently our openssl code is expecting a private key to perform handshake.
When smart card is used, private_key is updated with NULL at SSL_ACCEPT().
Hence, its throwing as no shard cipher during handshake.

Please provide a sample application how to program openssl for smart card
 where private key is not known.

Thanks in advance.

Rajeswari.

Re: simple https server using openssl

Jason Gerfen — 2013-05-17T18:02:37

Please do not double post to the same question to both mailing lists.
openssl s_client is just that, a client not a server.

If your looking for something other than a web server implementation of the
SSL/TLS protocol perhaps something higher level like node.js will suffice


On Fri, May 17, 2013 at 11:34 AM, Indtiny s <indtiny< at >gmail.com> wrote:

[openssl.org #3049] c_rehash skips PEM files with windows line feeds

Arnis Par?ovs via RT — 2013-05-17T16:08:23

Perl script 'c_rehash' does not process PEM files that have
CRLF line feeds.
OpenSSL command line tool does not have a problem parsing PEM files with 
windows line feeds.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev< at >openssl.org
Automated List Manager                           majordomo< at >openssl.org

Re: Integrity Check Value (ICV)

Matt Caswell — 2013-05-17T08:17:43

The authentication tag is calculated during the encryption operation.
It must then be passed along with the encrypted message. The
decryption operation requires both parts. It is safe to pass the tag
"in the clear".

Matt
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev< at >openssl.org
Automated List Manager                           majordomo< at >openssl.org

[PATCH][RFC] CPU Jitter random number generator

Stephan Mueller — 2013-05-17T07:12:57

Hi,

[1] patch at http://www.chronox.de/jent/jitterentropy-20130516.tar.bz2

To overcome the insufficient amount of entropy present (at least) on a
Linux box, I implemented the CPU Jitter random number generator
available at http://www.chronox.de/ . The heart of the RNG is about 30
lines of easy to read code. The readme in the main directory explains
the different code files. The new version now implements the RNG as an
OpenSSL engine as well as provides a patch for RAND_poll.

The documentation of the CPU Jitter random number generator
(http://www.chronox.de/jent/doc/index.html and PDF at
http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf -- the graphs and
pictures are better in PDF) offers a full analysis of:

- the root cause of entropy

- a design of the RNG

- statistical tests and analyses

- entropy assessment and explanation of the flow of entropy

The document also explains the core concept to have a fully
decentralized entropy collector for every caller in need of entropy.

The appendix of the documentation contains example use cases by
providing link code to the Linux kernel crypto API, libgcrypt and
OpenSSL. Links to other cryptographic libraries should be straight
forward to implement. These implementations follow the concept of
decentralized entropy collection.

The man page provided with the source code explains the use of the API
of the CPU Jitter random number generator.

The test cases used to compile the documentation are available at the
web site as well.

Ciao
Stephan

Signed-off-by: Stephan Mueller <smueller< at >chronox.de>

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev< at >openssl.org
Automated List Manager                           majordomo< at >openssl.org

Re: Integrity Check Value (ICV)

yassine ahmed — 2013-05-16T13:35:10

Ok but for decryption part , based on the example
(http://marc.info/?l=openssl-cvs&m=135042865227553) we need to provide the
authentication tag(gcm-tag or tag)

i have integrate this code ,how can i get this variable to use it.




--
View this message in context: http://openssl.6102.n7.nabble.com/Integrity-Check-Value-ICV-tp45101p45148.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev< at >openssl.org
Automated List Manager                           majordomo< at >openssl.org

Re: Integrity Check Value (ICV)

Matt Caswell — 2013-05-15T21:38:34

The "Integrity Check Value" is known as the authentication tag.

In order to retrieve the tag you must call EVP_CIPHER_CTX_ctrl with a
"type" argument of EVP_CTRL_GCM_GET_TAG. A full example is available
here:

http://wiki.opensslfoundation.com/index.php/EVP_Authenticated_Encryption_and_Decryption

Also see the openssl manual:
http://wiki.opensslfoundation.com/index.php/Manual:EVP_EncryptInit%283%29#GCM_Mode

Matt
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev< at >openssl.org
Automated List Manager                           majordomo< at >openssl.org

Re: [openssl.org #3046] bug report, openssl 1.0.1e sha1 hash generation

Piotr Sikora — 2013-05-15T18:06:43

Hey,


root shell's built-in echo doesn't support "-n" parameter:

$ echo -n "12345" | openssl dgst -sha1 -hex
(stdin)= 8cb2237d0679ca88db6464eac60da96345513964
$ echo "-n 12345" | openssl dgst -sha1 -hex
(stdin)= 10298ad22a68325ec5b2a69f209cac87135a5884

Best regards,
Piotr Sikora
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev< at >openssl.org
Automated List Manager                           majordomo< at >openssl.org