Re: X52219/X448 export public key coordinates

[Kyle Hamilton]

The reason has to do with the type of curve representation. X25519 is
typically represented in (I believe, but I'm not an expert and I haven't
looked at the primary sources recently so take this with a grain of salt)
Montgomery form. Its digital signature counterpart Ed25519 uses the same
curve represented in Edwards form.

Conversely, the NIST curves are in Weierstrass form. The EC_KEY interface
deals solely with Weierstrass form.

To my understanding, you can convert any curve to any representation.
However, different forms can be acted on with different values at different
levels of efficiency, which is why the different forms exist.

I hope this helps!

-Kyle H


On Fri, Nov 18, 2022, 11:47 ORNEST Matej - Contractor via openssl-users <
openssl-users@openssl.org> wrote:

> Yeah, of course, sorry for the typo. I’ve already found a solution that
> seems to be working by using EVP_PKEY_get_raw_public_key() for these types
> of curves. I was confused why it’s not working with EC_KEY interfaces
> though it’s type of elliptic curve. Then I found somewhere that it’s
> implemented outside the context of EC. It’s not clear to me why but I
> believe there’s a good reason for it.
> Anyway, thanks for your answer!
>
> Regards
> Matt
>
> On 18. 11. 2022, at 17:13, Kyle Hamilton  wrote:
>
> 
> X25519?
>
> On Mon, Nov 14, 2022, 05:23 ORNEST Matej - Contractor via openssl-users <
> openssl-users@openssl.org> wrote:
>
>> Hi all,
>>
>>
>>
>> I need to implement support for X52219/X448 for DH key exchange (and
>> Ed52219/Ed448 for DSA) elliptic curves in our project. I need to export
>> public key for DH exchange in form of DER encoded chunk in form
>> tag+X-coordinate+Y-coordinate. Thus I need to get EC_POINT from EVP_PKEY
>> and encode it as needed. I understand that those key types differs from EC
>> types in way that I need just X coordinate and a flag bit to reconstruct
>> the key, but still, how do I get the X coordinate?
>>
>> My solution works for all other EC types such as SecpX and Brainpool
>> families, but not for X52219/X448 keys and I do not completely understand
>> why. Specifically when I decode public key previously encoded with
>> i2d_PUBKEY() to EVP_PEKY and try to get EC_KEY by calling
>> EVP_PKEY_get0_EC_KEY(), it returns NULL and issues an error that it’s not
>> an EC key…
>>
>>
>>
>> I’m using following code:
>>
>>
>>
>> EVP_PKEY *key = … // Decode from DER encoded public key
>>
>>
>>
>> if(key != nil) {
>>
>>
>>
>> EC_KEY *ecKey = EVP_PKEY_get0_EC_KEY(key);
>>
>>  /// When X52219 or X448 key is passed, ecKey is NULL
>>
>> if(ecKey != NULL) {
>>
>> const EC_POINT *point = EC_KEY_get0_public_key(ecKey);
>>
>> const EC_GROUP *group = EC_KEY_get0_group(ecKey);
>>
>>
>>
>> if(point != NULL && group != NULL) {
>>
>> BIGNUM *bnX = BN_new();
>>
>> BIGNUM *bnY = BN_new();
>>
>>
>>
>> if(EC_POINT_get_affine_coordinates(group, point, bnX,
>> bnY, NULL)) {
>>
>> char *hexX = BN_bn2hex(bnX);
>>
>> char *hexY = BN_bn2hex(bnY);
>>
>>
>>
>> // Convert to custom data structures
>>
>>   …
>>
>> }
>>
>>
>>
>> BN_free(bnX);
>>
>> BN_free(bnY);
>>
>> }
>>
>> }
>>
>> }
>>
>>
>>
>>
>>
>> Is there any way how to export those key types in desired format?  I’m
>> using OpenSSL version 1.1.1q.
>>
>>
>>
>> Thank you very much for any hint
>>
>> Matt
>>
>

Re: X52219/X448 export public key coordinates

[Kyle Hamilton]

X25519?

On Mon, Nov 14, 2022, 05:23 ORNEST Matej - Contractor via openssl-users <
openssl-users@openssl.org> wrote:

> Hi all,
>
>
>
> I need to implement support for X52219/X448 for DH key exchange (and
> Ed52219/Ed448 for DSA) elliptic curves in our project. I need to export
> public key for DH exchange in form of DER encoded chunk in form
> tag+X-coordinate+Y-coordinate. Thus I need to get EC_POINT from EVP_PKEY
> and encode it as needed. I understand that those key types differs from EC
> types in way that I need just X coordinate and a flag bit to reconstruct
> the key, but still, how do I get the X coordinate?
>
> My solution works for all other EC types such as SecpX and Brainpool
> families, but not for X52219/X448 keys and I do not completely understand
> why. Specifically when I decode public key previously encoded with
> i2d_PUBKEY() to EVP_PEKY and try to get EC_KEY by calling
> EVP_PKEY_get0_EC_KEY(), it returns NULL and issues an error that it’s not
> an EC key…
>
>
>
> I’m using following code:
>
>
>
> EVP_PKEY *key = … // Decode from DER encoded public key
>
>
>
> if(key != nil) {
>
>
>
> EC_KEY *ecKey = EVP_PKEY_get0_EC_KEY(key);
>
>  /// When X52219 or X448 key is passed, ecKey is NULL
>
> if(ecKey != NULL) {
>
> const EC_POINT *point = EC_KEY_get0_public_key(ecKey);
>
> const EC_GROUP *group = EC_KEY_get0_group(ecKey);
>
>
>
> if(point != NULL && group != NULL) {
>
> BIGNUM *bnX = BN_new();
>
> BIGNUM *bnY = BN_new();
>
>
>
> if(EC_POINT_get_affine_coordinates(group, point, bnX,
> bnY, NULL)) {
>
> char *hexX = BN_bn2hex(bnX);
>
> char *hexY = BN_bn2hex(bnY);
>
>
>
> // Convert to custom data structures
>
>   …
>
> }
>
>
>
> BN_free(bnX);
>
> BN_free(bnY);
>
> }
>
> }
>
> }
>
>
>
>
>
> Is there any way how to export those key types in desired format?  I’m
> using OpenSSL version 1.1.1q.
>
>
>
> Thank you very much for any hint
>
> Matt
>

Re: Questions about legacy apps/req.c code

[Kyle Hamilton]

>From a conceptual perspective, I think "creating a CSR" should be different
than "signing a CSR with a given keypair", and on that reason alone I'd
separate them, allowing some small code duplication.

The difference between "signing with a certified key" and "signing with its
own key" is really just a matter of determining the IssuerDN to put into
the tbsCertificate, and that can be either an automatic process (a flag on
the certificate generation call, an automatic verification that the signing
key matches the key to be signed, the certificate generation call being
provided a NULL certificate or DN to identify the signer, or something
else) or a manual process (require library clients to know the lore that a
self-signed key also needs to copy the SubjectDN to the IssuerDN).

But, "generate a certificate" isn't something I'd personally put into the
basic SSL or crypto handling libraries. The reason is because OpenSSL is
still used in many embedded systems that will never use that functionality,
and putting code paths in place that will never be used is both a waste of
code space and potentially an invitation for attackers to exploit their
presence. (The same goes for key generation, to a degree, but the value of
new key generation can at be either limited to Denial of Service or, at
best, reset the device for a new deployment.)

I know it'll never happen, but I'd love to see another libcrypto/libssl
client library (libx509, maybe?) be used for the more esoteric aspects of
creating and verifying certificates.

-Kyle H

On Tue, Dec 21, 2021, 22:25 Philip Prindeville <
philipp_s...@redfish-solutions.com> wrote:

> Hi,
>
> I'm trying to add a library routine (or routines) to generate a CSR and
> make that available to users of Openssl at the API level.
>
> I'm thinking the shortest path might be to extract code from apps/req.c as
> we know it's correct.
>
> My only problem (so far) is dealing with the multiple places it bifurcates
> based on gen_x509 (versus newreq) -- which David pointed out to me in a
> separate mail thread back in mid-October.
>
> What would be the downside to having two completely different code paths
> for handling -x509 (and gen_x509) i.e. a self-signed certificate versus
> generating a CSR?
>
> The latter would allow me to move the CSR code into a library and have the
> app exercise that API.
>
> The only downside I can see is that the self-signed certificate path might
> need to duplicate some of the library code.
>
> Is that acceptable?
>
> Thanks,
>
> -Philip
>
>

Re: Question on "unsupported certificate purpose" error when trying to read the certificate on the web server

[Kyle Hamilton]

An EE certificate is an "end entity" certificate, which identifies an
entity that isn't a certifier.

On Wed, Jul 21, 2021, 18:23 Thejus Prabhu  wrote:

> Thanks for your reply Viktor. I would like to add that this is a self
> signed certificate created on the server. What is EE certificate?
>
>
> On Wed, Jul 21, 2021 at 6:55 PM Viktor Dukhovni <
> openssl-us...@dukhovni.org> wrote:
>
>> On Wed, Jul 21, 2021 at 06:34:03PM -0400, Thejus Prabhu wrote:
>>
>> > verify error:num=26:unsupported certificate purpose
>>
>> The certificate in question is CA certificate, not an EE certificate.
>> Specifically, the key usage and Netscape Cert Type signal that its
>> purpose is exclusively to be a CA, not a TLS server.
>>
>> X509v3 Key Usage: critical
>> Certificate Sign, CRL Sign
>> Netscape Cert Type:
>> SSL CA
>>
>> >   Certificate:
>> >   Data:
>> >   Version: 3 (0x2)
>> >   Serial Number: 1 (0x1)
>> >   Signature Algorithm: sha1WithRSAEncryption
>> >   Issuer: O = Verint, C = US, CN = 192.168.1.200, L = Columbia,
>> OU = Verint
>> >   Validity
>> >   Not Before: Jul 21 20:51:12 2021 GMT
>> >   Not After : Jul 21 20:51:12 2022 GMT
>> >   Subject: O = Verint, C = US, CN = 192.168.1.200, L =
>> Columbia, OU = Verint
>> >   Subject Public Key Info:
>> >   Public Key Algorithm: rsaEncryption
>> >   RSA Public-Key: (2048 bit)
>> >   Modulus:
>> >   00:b8:e8:bd:08:10:e4:d9:2d:77:52:33:8c:15:30:
>> >   cf:89:a0:d4:bd:95:85:15:ba:54:37:8d:5b:17:e4:
>> >   4d:3f:a3:fb:0c:08:ee:7e:30:eb:5d:93:fd:db:f3:
>> >   51:85:60:91:66:04:e1:b2:55:fd:5a:cf:c1:7c:3a:
>> >   3b:4c:30:af:67:b8:2f:21:7c:42:a4:86:8e:d3:a8:
>> >   ea:b2:8e:22:f3:b7:08:90:ec:8f:7a:20:1a:ae:44:
>> >   45:8c:db:2c:ee:20:d9:56:7a:8b:b9:d0:b9:0b:5b:
>> >   ac:7b:e0:f4:53:29:b4:06:cb:5e:fd:cf:87:b7:5d:
>> >   9f:bb:e7:71:33:27:f8:b4:01:d5:78:75:5e:99:e1:
>> >   dc:7d:5b:12:78:12:d6:38:07:f5:73:3c:8e:9b:62:
>> >   d6:ae:30:f5:8f:31:7e:42:81:2d:10:b4:6a:2c:33:
>> >   7c:48:db:95:9c:af:a9:ca:8b:92:c2:93:93:59:7a:
>> >   a0:a6:42:dd:72:e8:b8:21:d8:75:05:7a:8f:47:19:
>> >   ca:3d:ae:89:a6:d3:87:fc:2a:02:c4:49:58:28:05:
>> >   d5:d2:a9:fc:f5:06:40:1e:35:38:2e:33:f3:31:f2:
>> >   c9:a8:16:6e:b9:0a:42:95:6e:de:1f:f7:3e:2d:c8:
>> >   34:64:00:77:d4:cf:5c:3d:28:78:ce:60:bd:e5:90:
>> >   09:a9
>> >   Exponent: 65537 (0x10001)
>> >   X509v3 extensions:
>> >   X509v3 Basic Constraints: critical
>> >   CA:TRUE
>> >   X509v3 Key Usage: critical
>> >   Certificate Sign, CRL Sign
>> >   X509v3 Subject Key Identifier:
>> >
>>  A2:FF:95:62:C7:85:BC:1A:FE:D5:0B:F8:F7:A8:B1:B4:BF:29:8B:7D
>> >   Netscape Cert Type:
>> >   SSL CA
>> >   Netscape Comment:
>> >   example comment extension
>> >   Signature Algorithm: sha1WithRSAEncryption
>> >73:f4:61:1c:f1:b7:d3:c4:e2:ae:b1:ea:1e:3f:b2:6b:bc:f3:
>> >85:80:a1:0d:a8:06:7e:5a:bd:2b:fe:13:ce:4d:80:4d:c8:3d:
>> >4a:95:f9:ee:9c:19:1d:6b:b4:57:79:72:d9:00:e7:d1:be:9c:
>> >c3:4f:2d:77:93:71:45:87:8f:99:bd:35:43:95:1b:69:31:71:
>> >f9:f4:ee:00:1f:cd:f7:f4:2e:b1:ae:e7:9c:8e:cb:ce:86:50:
>> >d8:1b:4e:3c:11:77:63:55:09:74:4c:89:ce:34:ae:4e:75:80:
>> >e8:9e:37:23:75:e2:eb:bf:27:f8:dc:07:9d:64:b3:96:01:84:
>> >4a:62:23:c9:52:0f:92:e1:4a:3f:db:c7:b9:82:e9:8b:bb:89:
>> >7f:6c:fc:90:da:e1:2b:e9:8f:a3:d2:8c:66:22:5a:4e:27:77:
>> >f9:88:0e:7c:87:45:c4:56:4b:c8:fa:93:7c:18:3a:d5:cd:a3:
>> >59:6e:e2:37:a6:45:57:e8:8f:1f:d6:65:b9:47:e4:5c:c0:83:
>> >80:63:ac:2d:1d:6a:0f:95:62:00:18:b0:66:4f:b7:76:5a:1f:
>> >f6:7c:27:f7:86:3e:8d:fc:1c:b0:d9:7c:60:44:61:e9:eb:ff:
>> >95:b4:31:67:df:d1:ce:fc:91:3e:f3:64:fa:ca:c8:29:16:3b:
>> >d4:ae:f4:0e
>> >   -BEGIN CERTIFICATE-
>> >   MIIDrjCCApagAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMQ8wDQYDVQQKDAZWZXJp
>> >   bnQxCzAJBgNVBAYTAlVTMRYwFAYDVQQDDA0xOTIuMTY4LjEuMjAwMREwDwYDVQQH
>> >   DAhDb2x1bWJpYTEPMA0GA1UECwwGVmVyaW50MB4XDTIxMDcyMTIwNTExMloXDTIy
>> >   MDcyMTIwNTExMlowWjEPMA0GA1UECgwGVmVyaW50MQswCQYDVQQGEwJVUzEWMBQG
>> >   A1UEAwwNMTkyLjE2OC4xLjIwMDERMA8GA1UEBwwIQ29sdW1iaWExDzANBgNVBAsM
>> >   BlZlcmludDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALjovQgQ5Nkt
>> >   d1IzjBUwz4mg1L2VhRW6VDeNWxfkTT+j+wwI7n4w612T/dvzUYVgkWYE4bJV/VrP
>> >   

Re: query on key usage OIDs

[Kyle Hamilton]

Also, OIDs for extendedKeyUsage can be defined per-application, so
there's no way to compile a full list of them.

-Kyle H

On Fri, Jul 16, 2021 at 4:23 AM Viktor Dukhovni
 wrote:
>
> > On 15 Jul 2021, at 11:55 pm, SIMON BABY  wrote:
> >
> > I am looking for openssl APIs to get all the OIDs associated with user 
> > certificate Key usage extension. For example my sample Key usage extension 
> > from the certificate is below:
> > X509v3 extensions:
> > X509v3 Key Usage: critical
> > Digital Signature, Key Encipherment
> >
> > I am looking for the APIs used to get the OIDs associated with  Digital 
> > Signature and Key Encipherment from the certificate.
>
> There are no keyUsage OIDs, the field is a bitstring:
>
>https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3
>
>   id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
>
>   KeyUsage ::= BIT STRING {
>digitalSignature(0),
>nonRepudiation  (1), -- recent editions of X.509 have
> -- renamed this bit to 
> contentCommitment
>keyEncipherment (2),
>dataEncipherment(3),
>keyAgreement(4),
>keyCertSign (5),
>cRLSign (6),
>encipherOnly(7),
>decipherOnly(8) }
>
> There are OIDs in the extendedKeyUsage:
>
> https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12
>
> --
> Viktor.
>

Re: Client certificate authentication

[Kyle Hamilton]

If he's trying to muck with the library, he's probably struggling with a
precompiled binary he doesn't have the source code to.

-Kyle H

On Thu, Mar 11, 2021, 11:48 Viktor Dukhovni 
wrote:

> > On Mar 11, 2021, at 2:16 PM, Robert Ionescu 
> wrote:
> >
> > I am searching for the functions in openssl used to verify the clients
> > certificate when using mutual authentication.
>
> The same code verifies peer certificate chains, whether client or server.
>
> > My intention is to find a way to log a wrong user certificate directly
> inside
> > the openssl source.
>
> What does "wrong" mean?  OpenSSL is a library, it has no business making
> decisions like writing log entries, that's an application prerogative, and
> any logging of diagnostic or audit trail events should in application code,
> not in OpenSSL library code.
>
> --
> Viktor.
>
>

Re: Question about SSL_ERROR_WANT_WRITE

[Kyle Hamilton]

If you get SSL_ERROR_WANT_WRITE, call the same function with the same
parameters and same buffer content immediately. (Same with
SSL_ERROR_WANT_READ.)

If you need to, stash those parameters in variables for ease of reference.
But don't do anything else on the SSL layer until you get a different
return value. (If you implement your own BIO layer, do what you need to do
in support of what you're asked to do for the raw I/O. But don't do
anything with the SSL layer until its internal state has moved past the
need to read or write to or from the BIO.)

-Kyle H

On Thu, Dec 10, 2020, 09:14 Cosmin Apreutesei 
wrote:

> Hello,
>
> I have a question regarding SSL_write() and returning SSL_ERROR_WANT_WRITE
> from the write callback.
>
> _After_ SSL_write() returns with SSL_ERROR_WANT_WRITE (because my write
> callback returned  SSL_ERROR_WANT_WRITE), can I _then_ send the data given
> to the calback and then call SSL_write() again (with the same arguments)
> and then in the second call to the callback return the number of bytes
> written? Is that a supported use of the API? (I'm asking because that's the
> only way I can use the API, I can't send the data inside the callback, I
> need to send it outside the callback, see below for why).
>
> In other words, is it guaranteed that on that second call to  SSL_write(),
> SSL will want to send the exact same data that it tried before when it
> failed, and not change its mind about it wants to send? Because
> technically, since SSL_ERROR_WANT_WRITE implies that "no data was sent",
> the state machine might as well advance and send something different at a
> later time (because it received data or something inside expired or
> whatever).
>
> 
>
> Why I need this: I'm using IOCP and LuaJIT which means I have two
> limitations:
>
> 1) Because I'm using a completion API as opposed to a readiness API, I
> can't just tell OpenSSL when the socket is writable and let it write to it,
> I need to write the data myself.
>
> 2) because LuaJIT doesn't allow me to yield from inside a C callback, I
> can't do async I/O inside the callback, I can only do it in between calls
> to SSL_read()/SSL_write().
>
> Any suggestions appreciated, thanks!
>
>

Re: Server application hangs on SS_read, even when client disconnects

[Kyle Hamilton]

There's another reason why you'll want to close your socket with
SSL_close(): SSL (and TLS) view a prematurely-closed stream as an
exceptional condition to be reported to the application. This is to
prevent truncation attacks against the data communication layer.
While your application may not need that level of protection, it helps
to keep the state of your application in lockstep with the state of
the TLS protocol.  If your application doesn't expect to send any more
data, SSL_close() sends another record across the TCP connection to
tell the remote side that it should not keep the descriptor open.

-Kyle H

On Fri, Nov 13, 2020 at 11:51 AM Michael Wojcik
 wrote:
>
> > From: Brice André 
> > Sent: Friday, 13 November, 2020 09:13
>
> > "Does the server parent process close its copy of the conversation socket?"
> > I checked in my code, but it seems that no. Is it needed?
>
> You'll want to do it, for a few reasons:
>
> - You'll be leaking descriptors in the server, and eventually it will hit its 
> limit.
> - If the child process dies without cleanly closing its end of the 
> conversation,
> the parent will still have an open descriptor for the socket, so the network 
> stack
> won't terminate the TCP connection.
> - A related problem: If the child just closes its socket without calling 
> shutdown,
> no FIN will be sent to the client system (because the parent still has its 
> copy of
> the socket open). The client system will have the connection in one of the 
> termination
> states (FIN_WAIT, maybe? I don't have my references handy) until it times out.
> - A bug in the parent process might cause it to operate on the connected 
> socket,
> causing unexpected traffic on the connection.
> - All such sockets will be inherited by future child processes, and one of 
> them might
> erroneously perform some operation on one of them. Obviously there could also 
> be a
> security issue with this, depending on what your application does.
>
> Basically, when a descriptor is "handed off" to a child process by forking, 
> you
> generally want to close it in the parent, unless it's used for parent-child
> communication. (There are some cases where the parent wants to keep it open 
> for
> some reason, but they're rare.)
>
> On a similar note, if you exec a different program in the child process (I 
> wasn't
> sure from your description), it's a good idea for the parent to set the 
> FD_CLOEXEC
> option (with fcntl) on its listening socket and any other descriptors that 
> shouldn't
> be passed along to child processes. You could close these manually in the 
> child
> process between the fork and exec, but FD_CLOEXEC is often easier to maintain.
>
> For some applications, you might just dup2 the socket over descriptor 0 or
> descriptor 3, depending on whether the child needs access to stdio, and then 
> close
> everything higher.
>
> Closing descriptors not needed by the child process is a good idea even if you
> don't exec, since it can prevent various problems and vulnerabilities that 
> result
> from certain classes of bugs. It's a defensive measure.
>
> The best source for this sort of recommendation, in my opinion, remains W. 
> Richard
> Stevens' /Advanced Programming in the UNIX Environment/. The book is old, and 
> Linux
> isn't UNIX, but I don't know of any better explanation of how and why to do 
> things
> in a UNIX-like OS.
>
> And my favorite source of TCP/IP information is Stevens' /TCP/IP Illustrated/.
>
> > May it explain my problem?
>
> In this case, I don't offhand see how it does, but I may be overlooking 
> something.
>
> > I suppose that, if for some reason, the communication with the client is 
> > lost
> > (crash of client, loss of network, etc.) and keepalive is not enabled, this 
> > may
> > fully explain my problem ?
>
> It would give you those symptoms, yes.
>
> > If yes, do you have an idea of why keepalive is not enabled?
>
> The Host Requirements RFC mandates that it be disabled by default. I think the
> primary reasoning for that was to avoid re-establishing virtual circuits (e.g.
> dial-up connections) for long-running connections that had long idle periods.
>
> Linux may well have a kernel tunable or similar to enable TCP keepalive by
> default, but it seems to be switched off on your system. You'd have to consult
> the documentation for your distribution, I think.
>
> By default (again per the Host Requirements RFC), it takes quite a long time 
> for
> TCP keepalive to detect a broken connection. It doesn't start probing until 
> the
> connection has been idle for 2 hours, and then you have to wait for the TCP
> retransmit timer times the retransmit count to be exhausted - typically over 
> 10
> minutes. Again, some OSes let you change these defaults, and some let you 
> change
> them on an individual connection.
>
> --
> Michael Wojcik
>

Re: Cert hot-reloading

[Kyle Hamilton]

Could this be dealt with by the simple removal of any caching layer
between an SSL_CTX and a directory processed by openssl c_rehash?
Would reading the filesystem on every certificate verification be too
heavy for your use case?

On Sun, Aug 30, 2020 at 7:20 PM Jordan Brown
 wrote:
>
> Well, I can restate the problem that I encountered.
>
> We deliver an integrated storage system.  Under the covers it is a modified 
> Solaris running a usual collection of proprietary and open-source components. 
>  We supply an administrative user interface that, among many other things, 
> lets you manage a list of "trusted" certificates - typically CA certificates 
> that a program would use to authenticate its peers.  That is, it's the 
> equivalent of Firefox's Tools / Options / Privacy & Security / Certificates / 
> View Certificates, and the "Servers" and "Authorities" tabs there, with the 
> additional tidbit that for each certificate you can control which services 
> (e.g. LDAP, et cetera) that certificate is trusted for.
>
> When an administrator makes a change to the trusted-certificates list, we 
> want that change to take effect, system-wide.
>
> The problem is that that means that some number of processes with active 
> OpenSSL contexts need to drop those contexts and recreate them, and we don't 
> know which processes those are.  Client operations are typically driven 
> through a library, not a separate daemon, and so there's no centralized way 
> to know which processes might be TLS clients.  In addition, there's the 
> question of how to *tell* the process to recreate the context.  Simply 
> restarting them may involve disruption of various sorts.
>
> What we'd like would be for OpenSSL to, on every authentication, stat the 
> file or directory involved, and if it's changed then wipe the in-memory cache.
>
> Yes, aspects of this are system-specific, but that's true of many things.  
> There could easily be an internal API that captures a current-stage object, 
> and another that answers "is this still the same".  The default 
> implementation could always say "yes".
>
> --
> Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

Re: Cert hot-reloading

[Kyle Hamilton]

I'm not sure I can follow the "in all cases it's important to keep the key
and cert in the same file" argument, particularly in line with openat()
usage on the cert file after privilege to open the key file has been
dropped.  I agree that key/cert staleness is important to address in some
manner, but I don't think it's necessarily appropriate here.

I also don't think it's necessarily okay to add a new requirement that e.g.
letsencrypt clients reconcatentate their keys and certs, and that all of
the Apache-style configuration guides be rewritten to consolidate the key
and cert files. On a simple certificate renewal without a rekey, the best
current practice is sufficient.  (As well, a letsencrypt client would
possibly need to run privileged in that scenario to reread the private key
file in order to reconcatenate it, which is not currently actually
necessary.  Increasing the privileges required for any non-OS service for
any purpose that isn't related to OS kernel privilege requirements feels a
bit disingenuous.)

Of course, if you want to alter the conditions which led to the best
current practice (and impose retraining on everyone), that's a different
matter.  But I still think increasing privilege requirements would be a bad
thing, under the least-privilege principle.

-Kyle H

On Sun, Aug 30, 2020, 18:36 Viktor Dukhovni 
wrote:

> On Sun, Aug 30, 2020 at 05:45:41PM -0500, David Arnold wrote:
>
> > If you prefer this mailing list over github issues, I still want to ask
> > for comments on:
> >
> > Certificate hot-reloading #12753
> > 
> >
> > Specifically, my impression is that this topic has died down a bit and
> > from the linked mailing list threads, in my eye, no concrete conclusion
> > was drawn.
> >
> > I'm not sure how to rank this motion in the context of OpenSSL
> > development, but I guess OpenSSL is used to producing ripple effects,
> > so the man-hour argument might be a genuinely valid one.
> >
> > Please inform my research about this issue with your comments!
>
> This is a worthwhile topic.  It has a few interesting aspects:
>
> 1.  Automatic key+cert reloads upon updates of key+cert chain PEM
> files.  This can be tricky when processes start privileged,
> load the certs and then drop privs, and are no longer able
> to reopen the key + cert chain file.
>
> - Here, for POSIX systems I'd go with an approach where
>   it is the containing directory that is restricted to
>   root or similar, and the actual cert files are group
>   and or world readable.  The process can then keep
>   the directory file descriptor open, and then openat(2)
>   to periodically check the cert file, reloading when
>   the metadata changes.
>
> - With non-POSIX systems, or applications that don't
>   drop privs, the openat(2) is not needed, and one
>   just checks the cert chain periodically.
>
> - Another option is to use passphrase-protected keys,
>   and load the secret passphrase at process start from
>   a separate read-protected file, while the actual
>   private key + cert chain file is world readable,
>   with the access control via protecting the passphrase
>   file.
>
> - In all cases, it is important to keep both the private
>   key and the cert in the same file, and open it just
>   once to read both, avoiding races in which the key
>   and cert are read in a way that results in one or
>   the other being stale.
>
> 2.  Having somehow obtained a new key + cert chain, one
> now wants to non-disruptively apply them to running
> servers.  Here there are two potential approaches:
>
> - Hot plug a new pointer into an existing SSL_CTX structure.
>   While the update itself could be made atomic, the readers
>   of such pointers might read them more than once to separately
>   extract the key and the cert chain, without checking that
>   they're using the same pointer for both operations.
>
>   This is bound to be fragile, though not necessarily
>   impossible.
>
> - Build a new SSL_CTX, and use it to accept *new* connections,
>   while existing connections use whatever SSL_CTX they started
>   with.  I believe this can work well, because "SSL" handles
>   increment the reference count of the associated SSL_CTX
>   when they're created, and decrement it when destroyed.
>
>   So when you create a replacement SSL_CTX, you can just
>   SSL_CTX_free() the old, and it will only actually
>   be deleted when the last SSL connection tied to that
>   SSL_CTX is destroyed.
>
>   It is true that typical SSL_CTX construction is modestly
>   expensive (loading CA stores and the like) but some of
>   that could be 

Re: OpenSSL compliance with Linux distributions

[Kyle Hamilton]

It is never recommended to upgrade you distribution's version of OpenSSL
with one you compile yourself.  Doing so will often break all software
installed by the distribution that uses it.

If you need functionality from newer versions of OpenSSL, your options are
to upgrade your OS version, or to install a local copy of OpenSSL and
manually compile and link local copies of the applications that need the
newer functionality.

(Newer versions of OpenSSL do not maintain the same Application Binary
Interface (ABI), which means that binaries compiled against older versions
will not correctly operate or dynamically link against newer libraries.
Also, distributions such as Debian can modify the ABI in such a way that
nothing distributed directly by openssl.org can be compiled to meet it
without source code modification.)

-Kyle H

On Wed, Aug 5, 2020, 14:49 Patrick Mooc  wrote:

> Hello,
>
> I'm using an old version of OpenSSL (0.9.8g) on an old Linux Debian
> distribution (Lenny).
>
> Is it possible to upgrade OpenSSL version without upgrading Linux Debian
> distribution ?
> If yes, up to which version of OpenSSL ?
>
> Are all versions of OpenSSL compliant with all Linux Debian distribution ?
>
>
> Thank you in advance for your answer.
>
> Best Regards,
>
>

Re: Master fails tests (mentioning # TODO Currently not supported)

[Kyle Hamilton]

(I'm not an OpenSSL developer, but I know enough of development
processes to explain what I see here.  Actual OpenSSL developers
should correct me if I'm wrong.)

Most likely, yes this is currently expected.  Since it's a dev branch,
not a release branch, it's not expected to have everything internally
consistent.

Under test-driven development, one writes the tests for the behavior
one expects to implement before one writes the code to implement that
behavior.  This is primarily to commit to the contract, and to ensure
that the contract is fulfilled with the test data.

A comment of "TODO Currently not supported" in the output of a failed
test implies intent to support it in the next release, but the support
hasn't yet been implemented.

-Kyle H

On Thu, Jul 9, 2020 at 10:22 AM Blumenthal, Uri - 0553 - MITLL
 wrote:
>
> MacOS 10.15.5, Xcode-11.5, current OpenSSL master (3.0 dev)
>
> Is this expected:
>
>
> genpkey: Error setting ec_param_enc:explicit parameter:
> C00D090F0100:error::digital envelope 
> routines:legacy_ctrl_str_to_param:command not 
> supported:crypto/evp/pmeth_lib.c:1011:
> ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC 
> -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' 
> -text => 1
> not ok 1 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' 
> (text) # TODO Currently not supported
> # 
> --
> #   Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with 
> ec_param_enc:'explicit' (text)'
> #   at test/recipes/15-test_genec.t line 37.
> genpkey: Error setting ec_param_enc:explicit parameter:
> C0CDBE160100:error::digital envelope 
> routines:legacy_ctrl_str_to_param:command not 
> supported:crypto/evp/pmeth_lib.c:1011:
> ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC 
> -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' 
> -outform PEM -out ecgen.Oakley-EC2N-3.explicit.pem => 1
> not ok 2 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' 
> (PEM) # TODO Currently not supported
> # 
> --
> #   Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with 
> ec_param_enc:'explicit' (PEM)'
> #   at test/recipes/15-test_genec.t line 37.
> genpkey: Error setting ec_param_enc:explicit parameter:
> C01D251B0100:error::digital envelope 
> routines:legacy_ctrl_str_to_param:command not 
> supported:crypto/evp/pmeth_lib.c:1011:
> ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC 
> -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' 
> -outform DER -out ecgen.Oakley-EC2N-3.explicit.der => 1
> not ok 3 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' 
> (DER) # TODO Currently not supported
> # 
> --
> #   Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with 
> ec_param_enc:'explicit' (DER)'
> #   at test/recipes/15-test_genec.t line 37.
> genpkey: Error setting ec_param_enc:explicit parameter:
> C07DD70A0100:error::digital envelope 
> routines:legacy_ctrl_str_to_param:command not 
> supported:crypto/evp/pmeth_lib.c:1011:
> ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 
> 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -text => 1
> not ok 4 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' 
> (text) # TODO Currently not supported
> # 
> --
> #   Failed (TODO) test 'genpkey EC key on Oakley-EC2N-3 with 
> ec_param_enc:'explicit' (text)'
> #   at test/recipes/15-test_genec.t line 37.
> genpkey: Error setting ec_param_enc:explicit parameter:
> C00D34120100:error::digital envelope 
> routines:legacy_ctrl_str_to_param:command not 
> supported:crypto/evp/pmeth_lib.c:1011:
> ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 
> 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform 
> PEM -out ecgen.Oakley-EC2N-3.explicit.pem => 1
> not ok 5 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' 
> (PEM) # TODO Currently not supported
> # 
> --
> #   Failed (TODO) test 'genpkey EC key on Oakley-EC2N-3 with 
> ec_param_enc:'explicit' (PEM)'
> #   at test/recipes/15-test_genec.t line 37.
> genpkey: Error setting ec_param_enc:explicit parameter:
> C0FDFE100100:error::digital envelope 
> routines:legacy_ctrl_str_to_param:command not 
> supported:crypto/evp/pmeth_lib.c:1011:
> ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 
> 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform 
> DER -out ecgen.Oakley-EC2N-3.explicit.der => 1
> 

Re: distributed secret key

[Kyle Hamilton]

Actually, I was wrong about the prior one.
https://patents.google.com/patent/US6411716 looks like it has a distributed
CA function with multi-step, multi-fragment signatures.  (This looks
fascinating, and I'm going to study it over the weekend -- still in a
lockdown, so no real Memorial Day party for me.)

-Kyle H

On Sun, May 24, 2020, 14:59 Kyle Hamilton  wrote:

> From glancing at the abstract, https://patents.google.com/patent/US5799086
> looks like it might be the one?  It also says that it is expired,
> expiration having been anticipated on 2014-01-13.
>
> -Kyle H
>
> On Sun, May 24, 2020, 11:54 Salz, Rich  wrote:
>
>>
>>- In any case, I am unaware of any existing system which meets your
>>requirement 3.  Admittedly, I haven't specifically searched for such.
>>
>>
>>
>> CertCo (now defunct, don’t know who has the intellectual property) had a
>> patent that did ALL of the things.  RSA keygen, split the key, each key
>> signs the data, looks like an RSA signature, then when enough have been
>> done, combine them and it matches the original pre-split public key.  That,
>> and the followon patents, are cool.  Don’t know if they’re expired or not.
>>
>>
>>
>> To answer the main question: OpenSSL doesn’t do anything remotely in this
>> area.  The closest is multi-prime RSA.
>>
>

Re: distributed secret key

[Kyle Hamilton]

>From glancing at the abstract, https://patents.google.com/patent/US5799086
looks like it might be the one?  It also says that it is expired,
expiration having been anticipated on 2014-01-13.

-Kyle H

On Sun, May 24, 2020, 11:54 Salz, Rich  wrote:

>
>- In any case, I am unaware of any existing system which meets your
>requirement 3.  Admittedly, I haven't specifically searched for such.
>
>
>
> CertCo (now defunct, don’t know who has the intellectual property) had a
> patent that did ALL of the things.  RSA keygen, split the key, each key
> signs the data, looks like an RSA signature, then when enough have been
> done, combine them and it matches the original pre-split public key.  That,
> and the followon patents, are cool.  Don’t know if they’re expired or not.
>
>
>
> To answer the main question: OpenSSL doesn’t do anything remotely in this
> area.  The closest is multi-prime RSA.
>

Re: distributed secret key

[Kyle Hamilton]

There are two ways to handle multiple authorizations needed:
1) Secret data is shared across multiple locations/holders, or
2) Secret data is stored in a trusted system which itself requires multiple
authorizations.

You could perhaps put together multiple trusted systems, each of which has
a share of the secret data, and then have single authorizations for each of
those multiple systems.  But that that point, you're opening up a huge can
of logistical worms that you seriously need to examine through the lens of
a threat model evaluation, particularly against potentially rogue system
administrators and backup operators.

There is no possible way to have a distributed secret key without
distributing secret data across multiple entities/systems, though.  Whether
those entities are in the custody of those who possess the authority to use
them is unimportant, but if they are not then your threat model must
include attacks by those whose custody those entities/systems are actually
in. (Multiple encrypted containers/home directories for those shares might
work on the same system, but you still need to "send the secret data
around" to each of them.)

In any case, I am unaware of any existing system which meets your
requirement 3.  Admittedly, I haven't specifically searched for such.

-Kyle H

On Sun, May 24, 2020, 05:04 Erich Eckner  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> we're looking into setting up a CA with openssl, but we would like to
> distribute the secret key amongst multiple persons. We're aware of
> Shamir's secret sharing algorithm, but we'd like to know if there is some
> algorithm supported by openssl, that fulfills the following requirements
> (2 and 3 are not fulfilled by Shamir's algorithm):
>
> 1. Secret key shared amongst N persons, M the key.
>
> 2. No secret material (or parts thereof) needs to be sent around,
> preferably not even during creation of the key.
>
> 3. Secret key will not be assembled from the shares for the acutal
> operation. E.g. each share operates independently, and the intermediate
> result is sent around, after M keyparts operated on it, the signature is
> complete and can be used.
>
> If this is not supported by openssl, we're also open for suggestions of
> other (open source, free-to-use) software, that can achieve this and
> creates standard X.509 certificates (not sure if I termed that correctly).
>
> Thank you in advance!
>
> Regards,
> Erich
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7KRVMACgkQCu7JB1Xa
> e1rhyBAAvzJUrwcyRLpdme/mWsF/ftuA8nqv/ccw4be9Q1Y/S72MU/7UhKW2dBE0
> jp2tBV4zq5D3i37ElCy+Mco97cCQ+Ikg3pOtYaMYkK0hoybBlyX6onX0Y7jQhP2W
> N2v07HaN5RxtunxJgh7wUkWMy5arigKY9e645vJh5c8Ii5pwBb8QMwwMUJfb/1Hv
> 5yrF4x8la3lmqQSsAwkj0FFhAAmh+Xe/v4D+uoEzmTHY7vi9hGJsAAYNmJkwsIAb
> M/lK43wZRAXVbotFOVrud10wchBOSUtY0w6T5apmNJ/ArA61EbuFVtUUjjBYiv87
> oVxr+3pydjJLDW4WczcKLKQdNbhGPhmmz4DDHxvhLXSTrtFAPUm4Qb3VeM1AO0it
> Gs943eoBkUrga6813sBmulbtM3fnfDbJro0/ZqQnh4/vRKQUy6LvMj2W/M/8Fn1C
> M8um53J35/BAakZhOHaNvDrVty4bEJ0y1fNs7JNNpQfB+WjL8C04g2uExNJmAKgG
> 0dmZxDNGrPLKrltz+R39j0gbA4P1hnYkcgAYFcGho0z468IV5sgleHN3FhAp1qr5
> /TAuD2rwuPxT9wXf726n09iYJpq6jVhpBuF74mBNbyDdTzeeJtVq9mqngmhWqOCw
> KJcTXIhIem2wTA2yfhzf1PNK58hU55/lB36TnRryapp1rXLu1uU=
> =+60v
> -END PGP SIGNATURE-
>

Re: How to get all certs into a .der file.

[Kyle Hamilton]

application/pkix-pkipath
Defined in RFC4366 (section 8) and RFC6066 (section 10.1)

PkiPath ::= SEQUENCE OF Certificate

Within the sequence, the order of certificates is such that the subject of
the first certificate is the issuer of the second certificate, etc.

(It's also defined in ITU-T Recommendation X.509(2000) Corrigendum 1(2001)
| ISI/IEC 9594-82001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC
9594:8:2001.  However, the assignment of the application/pkix-pkipath
identifier was done in RFC4366 anf RFC6066.)

-Kyle H

On Fri, May 22, 2020, 13:57 Viktor Dukhovni 
wrote:

> On Thu, May 21, 2020 at 06:53:39PM -0400, paul h. roubekas wrote:
>
> > I have a requirement to convert all certs in a *.p12 file to a *.der file
> > for use in the curl command.
>
> Perhaps I can crystalise some of the replies for you.  The basic issue
> is that **DER is not a file format**, rather:
>
> * DER is binary encoding for a single data structure (object, a.k.a.
>   PDU or Protocol Data Unit), generally used only for objects with a
>   standardised ASN.1 schema.
>
> One can of course write a DER serialied data structure to a file,
> transmit it in network packet, ...
>
> But, what one can't do (in contrast with PEM) is just concatenate
> multiple DER objects together to get a meaningful multi-object store.
> For that, you need a standardised container structure that can be
> written in DER form, that *internally* holds multiple objects.
>
> Ideally, something less bletcherous than PKCS#12 (inflicted on humanity
> by some sadistic deity as punishment for ancestral sins).
>
> --
> Viktor.
>

Re: How to get all certs into a .der file.

[Kyle Hamilton]

There is a format that puts all DER certificates into a single
DER-formatted structure.  It is called PKIpath, and it's defined as
`SEQUENCE OF Certificate`.  The problem with it is that its order was
standardized by X.509 2001 TC1 to begin with the root and continue to the
leaf, which is backwards from how TLS present the certificate chain.
(Java's JCA/JCE were specified before that corrigendum issued, and its
PKIpath validation goes by the convention in use at the time to put the
leaf certificate first, like pem-certificate-chain.)

I don't have my computer open to get you the PKIX-WG RFCs which define it
and specify the same order as the TC1, but if you're curious you can chase
them down by looking up IANA's list of media types and searching for
"application/pkix-pkipath".

-Kyle H


On Fri, May 22, 2020, 00:55 Richard Levitte  wrote:

> Generally speaking, OpenSSL hasn't exactly encouraged multiple objects
> in one DER file.  While it's theoretically possible to have several
> objects in such a file file, there is code in OpenSSL where that's
> simply not considered.  For example, this snippet in the man-page
> 'X509_LOOKUP_file' is quite clear:
>
>Functions X509_load_cert_file and X509_load_crl_file can load both PEM
>and DER formats depending of type value. Because DER format cannot
>contain more than one certificate or CRL object (while PEM can contain
>several concatenated PEM objects) X509_load_cert_crl_file with
>FILETYPE_ASN1 is equivalent to X509_load_cert_file.
>
> The functions described there are also used by functions like
> X509_LOOKUP_load_file().
>
> Note that this may change going forward, as OSSL_STORE is gradually
> entering the scene, and does provide a bit better flexibility in this
> regard.
> (We have recently added an X509_LOOKUP variant that uses OSSL_STORE
> for its object retrieval, see the section 'OSSL_STORE Method' in
> doc/man3/X509_LOOKUP_hash_dir.pod in recent OpenSSL source, such as
> the alpha releases)
>
> Cheers,
> Richard
>
> On Fri, 22 May 2020 00:53:39 +0200,
> paul h. roubekas wrote:
> > I am a complete newbie to this list.
> >
> > I wanted to search the archive but found no such page.
> >
> > I have a requirement to convert all certs in a *.p12 file to a *.der
> file for use in the curl
> > command.
> >
> > The first hop to a *.pem file has all the certs.
> >
> > But the second hop only has one cert.  The I read the docs but found
> nothing that looked even
> > close.
> >
> > Hop 1
> >
> > openssl pkcs12 -chain -in trust.p12 -out ww_temp.pem  -password
> {redacted}
> >
> > Hop 2
> >
> > openssl x509 -outform der -in ww_temp.pem -out ww_temp.der
> >
> > The Question) How do I get all the certs in the .der file?
> >
> >
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
>

Re: How to get all certs into a .der file.

[Kyle Hamilton]

If you need multiple certificates in a single DER structure, you're looking
for something to create a "PKIpath". I've never heard of curl requiring
such, though.  Chances are it will handle the PEM chain just fine.

What curl command line are you trying to use?

-Kyle H

On Thu, May 21, 2020, 18:00 paul h. roubekas  wrote:

> I am a complete newbie to this list.
>
> I wanted to search the archive but found no such page.
>
>
>
> I have a requirement to convert all certs in a *.p12 file to a *.der file
> for use in the curl command.
>
> The first hop to a *.pem file has all the certs.
>
> But the second hop only has one cert.  The I read the docs but found
> nothing that looked even close.
>
> Hop 1
>
> openssl pkcs12 -chain -in trust.p12 -out ww_temp.pem  -password {
> *redacted*}
>
>
>
> Hop 2
>
> openssl x509 -outform der -in ww_temp.pem -out ww_temp.der
>
>
>
> The Question) How do I get all the certs in the .der file?
>

OCSP pregeneration

[Kyle Hamilton]

Is there a way to have OpenSSL's command line generate OCSP responses
for every entry in index.txt, without having to go through the process
of generating a blank (no-nonce, unsigned) request and then generating
a response to each one for each serial number therein?

-Kyle H

Re: mutual-TLS / mTLS Example with certificate problem

[Kyle Hamilton]

On a tangent, this file format (and order) was actually finally
standardized as "application/pem-certificate-chain" by RFC 8555
section 9.1 (the Automatic Certificate Management Environment
protocol, or ACME).

On Wed, May 6, 2020 at 2:59 PM Michael Wojcik
 wrote:
> Get rid of the call to use_certificate_file and put everything the server 
> should be sending into the chain file, in the order described in the OpenSSL 
> documentation: entity certificate, certificate for its issuer, and so on up 
> to and including the root. (I've just noticed the docs don't say whether 
> use_certificate_chain_file specifies SSL_BUILD_CHAIN_FLAG_NO_ROOT when it 
> calls add1_chain_cert, so offhand I don't know whether this will cause the 
> root to be included in the chain the server sends. But that shouldn't really 
> matter.)

Re: TLSv1 on CentOS-8

[Kyle Hamilton]

Note: This is better asked on the CentOS support forums, since it asks
about changes that CentOS made to OpenSSL.

This is an unsupported configuration, and will be overwritten if you audit
or reinstall the crypto-policies package.  Also, I haven't looked to see
where /etc/crypto-policies/back-ends/opensslcnf.config versus
/etc/crypto-policies/back-ends/openssl.config are used.

Since you're modifying the LEGACY policy (and the files in
/etc/crypto-policies/back-ends/ are all symlinks, and I don't want to give
information that would modify any security level without regard for knowing
what security level is currenty in place): You want to modify the
/usr/share/crypto-policies/LEGACY/openssl.txt file to append ":!RC4" to
it.  You should also modify
/usr/share/crypto-policies/LEGACY/opensslcnf.txt to append ":!RC4" to the
CipherString line, and ":!RC4-SHA" to the Ciphersuites line.

There are additional files in there that refer to other services and crypto
libraries, that you may wish to change as well.  The OpenSSL support lists
don't have any information about them.

-Kyle H

On Fri, Apr 17, 2020, 09:40 Junaid Mukhtar  wrote:

> Hi Tomas
>
> Is it possible to enable legacy protocols/ciphers but disable only one. In
> particular we want RC4-SHA to be disable
>
> 
> Regards,
> Junaid
>
>
> On Wed, Apr 15, 2020 at 5:13 PM Junaid Mukhtar 
> wrote:
>
>> Thanks a lot; It really helped
>>
>> 
>> Regards,
>> Junaid
>>
>>
>> On Wed, Apr 15, 2020 at 5:04 PM Tomas Mraz  wrote:
>>
>>> On Wed, 2020-04-15 at 16:57 +0100, Junaid Mukhtar wrote:
>>> > Hi Team
>>> >
>>> > I am trying to enable TLSv1 on CentOS-8. We don't have the ability to
>>> > upgrade the server unfortunately so we need to enable TLSv1 with
>>> > weak-ciphers on OpenSSL.
>>> >
>>> > I have tried to build the OpenSSL version manually using switches
>>> > "./config --prefix=/usr/local/openssl --openssldir=/usr/local/openssl
>>> > shared enable-weak-ssl-ciphers enable-deprecated enable-rc4 enable-
>>> > tls1 zlib" which ran successfully
>>> >
>>> > [root@2cb6477375aa openssl-OpenSSL_1_1_1c]# openssl version
>>> > OpenSSL 1.1.1c  28 May 2019
>>> >
>>> >
>>> > But i am still not able to run the "openssl s_client -connect "
>>> > command without specifying -tls1 in it. Build accepts the weak-
>>> > ciphers but not the tls1 version.
>>> >
>>> > Can someone please help me with this?
>>>
>>> You should not need to recompile openssl or anything.
>>>
>>> Just run:
>>>
>>> update-crypto-policies --set LEGACY
>>>
>>> and restart the service that is supposed to be providing the TLS1
>>> server or reboot the machine.
>>>
>>> The LEGACY crypto policy purpose is exactly for re-enabling some of the
>>> not-up-to-date protocols and crypto algorithms.
>>>
>>> --
>>> Tomáš Mráz
>>> No matter how far down the wrong road you've gone, turn back.
>>>   Turkish proverb
>>> [You'll know whether the road is wrong if you carefully listen to your
>>> conscience.]
>>>
>>>
>>>

Re: tbslen parameter in EVP_PKEY_sign() and EVP_PKEY_verify()

[Kyle Hamilton]

32 bytes means you're signing using RSA-WITH-SHA-256, yes?

tbs is the digest value you calculated, tbslen is the size in bytes of
the digest.

-Kyle H

On Tue, Apr 7, 2020 at 1:07 PM Jason Proctor  wrote:
>
> Esteemed cryptologists,
>
> Question regarding the "tbslen" parameter to the sign and verify
> functions. The documentation says --
>
> "The verified data (i.e. the data believed originally signed) is
> specified using the tbs and tbslen parameters."
>
> Which might indicate that tbslen is the length of the payload. However
> I found that I had to set this to the length of the *signature* to get
> these calls to work. The sign() operation fails at rsa_pmeth.c line
> 134, and the debugger does indeed tell me that it's expecting 32
> there, rather than the payload length which is 1024.
>
> Is this correct? Anything I'm missing, here?
>
> thanks for any clarity here
> Jason@Spatial

Re: Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client

[Kyle Hamilton]

ssl_prefer_server_ciphers on;

On Wed, Mar 11, 2020, 11:58 Kaushal Shriyan 
wrote:

>
>
> On Wed, Mar 11, 2020 at 6:36 PM Michael Wojcik <
> michael.woj...@microfocus.com> wrote:
>
>> To enforce the server's cipher order, use SSL_CTX_set_options(*ctx*,
>> SSL_CTX_get_options(*ctx*) | SSL_OP_CIPHER_SERVER_PREFERENCE).
>>
>> https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set_options.html
>>
>> --
>>
>>
>> Testing server preferences
>>  Has server cipher order? no (NOT ok)
>>   ...
>> No further cipher order check has been done as order is determined by the
>> client
>>
>>
>>
> Hi Michael,
>
> Thanks for the email. I am not sure if i understand it completely. what
> does the server's cipher order mean in layman's terms? Any example
> regarding To enforce the server's cipher order, use
> SSL_CTX_set_options(ctx, SSL_CTX_get_options(ctx) |
> SSL_OP_CIPHER_SERVER_PREFERENCE) to set it in /etc/nginx/nginx.conf. I am
> running Nginx web server.
>
> I have the below settings in /etc/nginx/nginx.conf
>
> server {
> listen 443 ssl;
> ssl_protocols TLSv1.2;
> ssl_ciphers
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
> ssl_prefer_server_ciphers off;
> }
>
> Please suggest. I look forward to hearing from you and thanks in advance.
>
> Best Regards,
>
> Kaushal
>

Re: Questions about using Elliptic Curve ciphers in OpenSSL

[Kyle Hamilton]

Be aware that you just posted your certificate's private key, and thus you
should regenerate a new keypair/certificate to use.  Otherwise, anyone who
can manipulate traffic to your machine can execute a man-in-the-middle
attack.

-Kyle H


On Fri, Feb 14, 2020, 07:40 Jason Schultz  wrote:

>
> Thank you for your response Thulasi, this helped. I'm posting this back to
> the OpenSSL users list in case it helps anyone else, and in case anyone can
> help with my additional questions. While waiting for responses, I've been
> able to find out how my certificate and keys were generated. I'd like to
> walk through that to hopefully verify I'm handling things correctly.
>
> First, here is how my EC parameters file was generated:
>
> openssl ecparam -name prime256v1 -genkey -out myecparamsfile.pem
>
> And the resulting file:
>
> M640A-SAIL:/etc/ssl # openssl ecparam -in myecparamsfile.pem -text
>
> ASN1 OID: prime256v1
>
> NIST CURVE: P-256
>
> -BEGIN EC PARAMETERS-
>
> BggqhkjOPQMBBw==
>
> -END EC PARAMETERS-
>
>  # openssl ecparam -in myecparamsfile.pem -text
>
> ASN1 OID: prime256v1
>
> NIST CURVE: P-256
>
> -BEGIN EC PARAMETERS-
>
> BggqhkjOPQMBBw==
>
> -END EC PARAMETERS-
>
> Is this good so far? Do I need the -genkey?
>
> Then I take this file and use it when I generate my certificate and
> private key pair, here is the openssl command I used:
>
> openssl req -nodes -sha256 -newkey ec:/etc/ssl/private/myecparamsfile.pem
> -keyout mykeyout.pem -new -out mycertfileout.pem -config
> /etc/ssl/openssl.cnf -x509 -days 365 -outform pem
> Generating a EC private key
> writing new private key to 'mykeyout.pem'
> 
>
> And the resulting key:
>
> # cat mykeyout.pem
> -BEGIN PRIVATE KEY-
> MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgbfUwVhomun9Q5IAY
> xTOAn+sDoXZ+k4UWkvUyfshPBJ6hRANCAAQsakFVUTV4JmfVJH31XOvHVhhBodnV
> 8evYCJSd2Jgo4uOomCSh3oekKL+Tia+LOmynygfvmneOX2YadoNr9uzH
> -END PRIVATE KEY-
>
> # openssl ec -noout -text -in mykeyout.pem
> read EC key
> Private-Key: (256 bit)
> priv:
> 6d:f5:30:56:1a:26:ba:7f:50:e4:80:18:c5:33:80:
> 9f:eb:03:a1:76:7e:93:85:16:92:f5:32:7e:c8:4f:
> 04:9e
> pub:
> 04:2c:6a:41:55:51:35:78:26:67:d5:24:7d:f5:5c:
> eb:c7:56:18:41:a1:d9:d5:f1:eb:d8:08:94:9d:d8:
> 98:28:e2:e3:a8:98:24:a1:de:87:a4:28:bf:93:89:
> af:8b:3a:6c:a7:ca:07:ef:9a:77:8e:5f:66:1a:76:
> 83:6b:f6:ec:c7
> ASN1 OID: prime256v1
> NIST CURVE: P-256
>
> And certificate:
>
> M740A-PMM1:/etc/ssl # openssl x509 -text -in mycertfileout.pem
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> e2:2f:c6:e4:bf:f1:de:20
> Signature Algorithm: ecdsa-with-SHA256
> Issuer: C=US, ST=NY, L=Loc, O=Org, OU=test, CN=My
> Name/emailAddress=t...@example.com
> Validity
> Not Before: Feb 13 16:11:39 2020 GMT
> Not After : Feb 12 16:11:39 2021 GMT
> Subject: C=US, ST=NY, L=Loc, O=Org, OU=test, CN=My
> Name/emailAddress=t...@example.com
> Subject Public Key Info:
> Public Key Algorithm: id-ecPublicKey
> Public-Key: (256 bit)
> pub:
> 04:2c:6a:41:55:51:35:78:26:67:d5:24:7d:f5:5c:
> eb:c7:56:18:41:a1:d9:d5:f1:eb:d8:08:94:9d:d8:
> 98:28:e2:e3:a8:98:24:a1:de:87:a4:28:bf:93:89:
> af:8b:3a:6c:a7:ca:07:ef:9a:77:8e:5f:66:1a:76:
> 83:6b:f6:ec:c7
> ASN1 OID: prime256v1
> NIST CURVE: P-256
> X509v3 extensions:
> X509v3 Subject Key Identifier:
> D6:8A:F3:3B:4E:A1:F8:F8:34:C1:1B:7A:EC:BF:9B:58:7F:68:4A:D9
> X509v3 Authority Key Identifier:
>
> keyid:D6:8A:F3:3B:4E:A1:F8:F8:34:C1:1B:7A:EC:BF:9B:58:7F:68:4A:D9
>
> X509v3 Basic Constraints:
> CA:TRUE
> Signature Algorithm: ecdsa-with-SHA256
>  30:44:02:20:37:f0:f7:f7:4a:b4:8e:8f:64:72:e4:d1:31:9f:
>  a1:36:c5:5d:f3:42:4c:24:37:75:cf:b6:55:b0:66:1b:6e:63:
>  02:20:39:18:81:f8:6c:86:3a:57:74:05:cc:99:6c:d9:dc:6a:
>  a2:20:98:4c:66:a1:97:d1:c7:ea:42:b4:01:1a:f7:b2
>
> Then I call the APIs as described in my first email to use them:
>
> ctx = SSL_CTX_new(TLS_method());
>
> status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM);
> status = SSL_CTX_use_certificate_file(ctx, ,,SSL_FILETYPE_PEM);
>
>
> // Verify the cert and key are a pair
> status = SSL_CTX_check_private_key(ctx);
>
>
> Then call the APIs to set the curves and allow the server to pick the
> appropriate curve for the client:
>
> status = SSL_CTX_set1_curves_list(ctx, "P-521:P-384:P-256");
> status = SSL_CTX_set_ecdh_auto(ctx, 1);
>
>
> That should be it, right? The EC parameters file has been used to generate
> the private key, it does not need to be read in by an API call.
>
> With the steps above, I get a successful TLS connection from a client
> using ECDHE-ECDSA-AES256-GCM-SHA384.
>
> And 

Re: Cloning a CSR or Cert. for a new CSR with a new key?

[Kyle Hamilton]

A CSR is self-signed to provide what's called "proof of possession" -- that
is, proof that the requester possesses the private key to the claimed
public key.  It doesn't act as a CA in that case, because the CSR is not an
actual Certificate structure.

-Kyle H

On Thu, Jan 30, 2020, 18:26 Douglas Morris via openssl-users <
openssl-users@openssl.org> wrote:

> Thanks, Dw.
>
> Interesting. I think I misunderstood this explanation about the -signkey
>  option: "This option causes the input file to be self signed using
> the supplied private key."
>
> Your input has me thinking that a certificate signing request is in fact
> self-signed like a self-signed certificate is self-signed. I think I
> mistakenly supposed any self-signing meant acting like a "mini CA". I shall
> give those two x509 options, '-x509toreq' and '-signkey', a try.
>
> Douglas Morris
>
>
> On Thursday, January 30, 2020, 3:51:45 PM EST, Dirk-Willem van Gulik <
> di...@webweaving.org> wrote:
>
>
>
>
> On 30 Jan 2020, at 21:38, Douglas Morris via openssl-users <
> openssl-users@openssl.org> wrote:
>
> I am trying to implement automated domain certificate renewal. A
> certificate signing request is sent to an ACME server and on success a
> certificate is returned. I'd like to be able to call OpenSSL to make a new
> key and then make a new certificate signing request just like the old one
> except for the replacement key pair file.
>
> I suppose the complete information beyond the new key data is available
> both in the old crs and the old certificate. I'm looking at the manpages of
> OpenSSL subcommands 'req' and 'x509'. The openssl x509 option '-x509toreq'
> gave me a momentary rush of hope, but then I read about the '-signkey'
> option, which seems to be exclusively about self-signing.
>
> Is 'cloning' the csr or cert. information semantically logical? Is it
> possible with OpenSSL?
>
> If I can't reliably extract the relevant data from the old csr or old
> certification, I suppose I must do it as usual with a dedicated config file
> and the '-batch' option:
>  openssl req -key  -new -config  -outform PEM -out
>  -batch
>
>
> openssl x509 -x509toreq should do the trick
>
> E.g.
>
> # generate test cert
> openssl req -x509 -new -subj /CN=foo -nodes -keyout x.key > x.crt
> openssl x509 -in x.crt -noout -text
>
> # turn test cert in a request
> openssl x509 -x509toreq -signkey x.key < x.crt
>
> Dw
>
>

Re: Generate nomative certificate from wildcard certificate

[Kyle Hamilton]

No, it's not possible,to use a webserver certificate to issue other
certificates of any kind.  (Oh, it is technically possible with openssl to
create certificates which might seem valid on the surface -- just use the
webserver key to generate a self-signed CA certificate with the same
Subject as is contained within your webserver certificate -- but such
certificates are actually invalid and will not work.)

See, the issue is that you need to use a CA to issue certificates, and all
publicly trusted web server certificates issued in the last 25+ years have
an extension called BasicConstraints which says that they are not CAs.  So,
all software which correctly validates certificates will immediately fail
the authentication process when presented with certificates which attempt
to chain through such webserver certificates.

Fortunately, this is not exactly an impediment to your proposed use case --
your webSSO portal software (and your webservers themselves, and your
internal document signature verification software itself, for that matter)
can be configured to accept authentication via certificates from any
particular CA, not merely any CA which has been publicly trusted by web
browsers.  What this means is that you can create your own CA to issue the
certificates to your webSSO portal users, with the caveat that they cannot
use those certificates to sign documents which must be authenticated
externally.

The necessary security analysis is the same whether you were to issue user
certificates using the webserver certificate or a certificate identifying
your own CA.  Among other things, you need to think about where and how the
keys are stored (not just for your CA but also for your users), how they're
generated, how the CA links each public key to the user it's linked to, how
users are prevented from using keys belonging to other users, what happens
when you need to make changes to the infrastructure [no infrastructute ever
remains static], what services will be accessible via the keys, what
operations can be performed by the holders of the keys, what happens when
an inevitable compromise happens (including but not limited to 'CA is
completely compromised and its private key learned by anyone who is
unauthorized', 'CA misissues a certificate', 'some user's certificate is
used by someone other than the user it identifies', 'employee a certificate
was issued to is terminated', and 'employee who knew the CA's private key
is terminated'), and whether the protections you bake into the key
infrastructure are sufficient to support those uses without giving rise to
liability for your organization.  And make sure you write down the limits
of what you're comfortable with in your infrastructure and why those are
the limits, so that they can be referred to down the road.  (No CA should
ever have its private key accessible from a world-accessible machine like a
webserver, because it increases the risk of that private key being
discovered by any hacker in the world.  This is one of the primary reasons
why webserver keys should never be also used as CA keys.)

In an ideal world, organizations would have X.500 Directory instances which
would be identified and authenticated by some trustworthy external identity
verifier, and which could issue certificates for their employees to be
trusted by external relying parties.  That's possibly what you're asking
for, by asking to use an externally-signed webserver certificate as your
issuer.  Unfortunately, that is not how our world currently exists (except
in the US military and aerospace contract space, to my knowledge, and
possibly in diplomatic channels and anything that other nations may have
done), and so we are basically in a position where companies must create
their own CAs by essentially saying "I am me" and building their own
internal infrastructures to trust those kinds of statement.  (And,
potentially, to then cross-certify other entities who make the same type of
assertion in a manner that they trust, which usually involves contracts and
due diligence -- but only so their infrastructures can trust those other
entities' users to do things that those contracts specify they need to do.)

Please note that I do not have direct knowledge of France's or the EU's
legal climate.  You may wish to inquire if such company certification
services do exist from your register of corporations.  But do not be
discouraged if they do not. You can still accomplish your stated purposes
without such services being provided.

Good luck!

-Kyle H


On Sat, Jan 25, 2020, 12:50 PEILLON Stephane  wrote:

> Hello
>
> I have a wildcard certificate to implement https on our websites via sub
> domains.
>
> is it possible to generate a nominative certificate from this certificate
> with openssl? (with an attribute of the type uid, name and function ...).
>
> I would like to be able to distribute certificates to each agent of the
> company to authenticate on our websso portal or electronically sign
> 

Re: Role Separation

[Kyle Hamilton]

OpenSSL is a toolkit, not a full implementation.  More importantly, it is a
library, so anyone who can link against it can perform all operations that
the library can support, and the library has no concept of role separation
built in.

As such, the 'openssl' commandline tool allows the use of any of its
subcommands by anyone who can run their executables.  This generally
includes 'root', which is also usually necessary for manipulating files
(keys, certs, and CA cert chains) which are owned by system users, like
'apache'.

There are many openssl subcommands which are useful for standard system and
network administrators.  s_client and s_server (to verify interoperability
and connectivity), x509 (to figure out what's broken and see if it's
something the PKI admin needs to deal with, in conjunction with the -noout
and -text parameters), verify (to figure out what's wrong with a cert chain
to make filing tickets for the pki admin more useful)... the only commands
I can really think of off the top of my head that could be legitimately
restricted are 'req' and 'ca'.  Usually, the 'ca' command is limited by
access to the CA key.  'req' generates a new certificate signing request,
but doesn't generate a new certificate.  The operations for a PKI admin
should in all cases include "generate your request, then send the request
that you just generated" rather than "submit some request that some other
schlub generated", which mitigates that particular potential disaster.

It might be possible to limit the execution of openssl subcommands using
SELinux roles and labels, but I don't think anyone's audited the
subcommands looking for functionality that should be limited to one role or
another.  The closest that's been done has been for the FIPS validation,
and (to my uncertain understanding) even that applies pretty much only to
the building and installation of the module.

If you do perform such an audit, I'd love to see your work.  (n.b. I'm not
a member of the OpenSSL team, so my opinions are mgmy own and no one
else's.)

-Kyle H

On Sun, Sep 15, 2019, 09:06 Jimmy Jung  wrote:

> I had been poking around the internet looking for implementations of Role
> Separation for OpenSSL (in this case in Centos).  I thought I should ask
> here as well.
>
>
>
> By “role separation” I’m thinking that only PKI roles can perform OpenSSL
> commands and system admins are restricted from these operations.
>
>
>
> Thanks
>
>
>
> jimmy
>

Re: 1.1.1d LD_LIBRARY_PATH

[Kyle Hamilton]

You might be able to set this in the equivalent of /etc/ld.so.conf and
rerun ldconfig(8), but those specific operations rely on the GNU dynamic
linker.  The only clue that suggests it may be GNU's dynamic linker is the
LD_LIBRARY_PATH environment variable name.  If it's not, you'll have to
look up your platform's dynamic linking process and set it yourself.

-Kyle H

On Fri, Sep 13, 2019, 23:12 Mal via openssl-users 
wrote:

> Hi,
>
> On restart on my host with version 1.1.1d , I have this problem:
> >
> HOST:/ # openssl version
> openssl: /usr/lib/arm-linux-gnueabihf/libssl.so.1.1: version
> `OPENSSL_1_1_1' not found (required by openssl)
> openssl: /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1: version
> `OPENSSL_1_1_1' not found (required by openssl)
>
>
> When i manually add LD_LIBRARY_PATH, we get back in business:
> >
> HOST:/ # export LD_LIBRARY_PATH=/os/openssl-1.1.1d
> HOST:/ # openssl version
> OpenSSL 1.1.1d  10 Sep 2019
>
>
>
> Would someone let me know how to add this path permanently, as currently
> i need to re-add on restart ?
>
> Thanks..
>
>

Re: CSR with only public key

[Kyle Hamilton]

If a CA signs a certificate without proof of possession of the private key,
the CA is enabling whoever does have that private key to look as though
they are the one who they sign the certificate for (i.e., impersonation).
The entire structure of PKI (the binding of the public half of a keypair to
some external identity) depends on this not happening.

More importantly, in the situation where the person submitting the unsigned
request can't prove possession, they know it is a situation where either
the private key is lost (and the certificate would be useless anyway) or
that impersonation is simply guaranteed.

There might be a scenario desired where the generation of the CSR isn't
done by the holder of the private key internal to a company (perhaps
because the holder of the private key is otherwise extremely busy), but
because there's no way to tell if that limited scenario is different from
the other scenarios based on available evidence, publicly trusted CAs are
required (by rules of the CABF) to reject non-proof-of-possession scenarios
entirely.

To answer your question, yes the error is because the request wasn't signed
with the private key.  As such, it's not a complete request, and doesn't
match the expected ASN.1 structure.

-Kyle H


On Thu, Sep 12, 2019, 02:47 Bharathi Prasad 
wrote:

> Hi,
> I have the public key of the client but not the private key. I am required
> to generate a CSR with only public key. I understand private key is
> required
> for Proof of Possession. However, as per my requirement I am supposed to
> create CSR only with public key and my CA would create a certificate.
>
> I was able to create a CSR with CX509CertificateRequestCertificate and
> CX509Enrollment classes using the available public key. When I try to read
> the contents the of CSR in openssl (i used this command: openssl req -in
> client.csr -noout -text) i get "unable to load X509 request".
>
> Is this happening because the CSR does not contain the signature of private
> key or the CSR is faulty.
>
> Kindly help me.
>
> Regards,
> Bharathi
>
>
>
> --
> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
>

Re: Will my application be FIPS 140-2 Certified under following conditions?

[Kyle Hamilton]

Also, on question b: No.  You need to build a compatible version of openssl
as specified in the User Guide, and link that version.  FIPS_mode_set()
tells the library to always and only use the implementations in the FIPS
canister; the canister does not replace the library entirely.

-Kyle H

On Wed, Jul 3, 2019, 11:55 Dipak B  wrote:

> Dear Experts,
>
> Can you please help me with the following question?
>
> My win32 desktop application uses 'libcurl' to interact with web service,
> in order to get my application FIPS 140-2 certified, following is the plan
> which I arrived at after going through the 'User Guide' and 'Security
> Policy' pdfs.
>
> Plan:
> a. After verifying HMAC-SHA1 of openssl-fips-2.0.16.tar.gz, build it to
> generate fipscanister.lib (FOM) as windows static library.
> b. Build libcurl as windows static library using above fipscanister.lib
> c. Link my desktop application with above libcurl.lib after adding
> FIPS_mode_set()
>
> Questions:
> a. On following points a, b,c, can I confirm that my application is FIPS
> 140-2 certified?
> b.  fipscanister.lib is always static library and it can be substituted
> for libssl.lib / ssleay.lib?
>
> Thank you,
> Deepak
>

Re: Will my application be FIPS 140-2 Certified under following conditions?

[Kyle Hamilton]

Step a. needs to verified the digest with an existing FIPS 140-2 validated
cryptography implementation.  Otherwise, to my understanding, this is the
correct sequence of events.

Do note that after building the fipscanister.lib, you will want to digest
it and print it on a certification letter that it was built as specified in
the Security Policy, signed and dated by the person who built it
(preferably also with details of the build chain).  Also, when you build
anything that links that library, you will want to verify the digest
against that letter before linking, and write a new letter specifying the
product name and version, the digest of the output, and that it was also
built in accordance with the Security Policy.  This should also be signed
and dated.  (these letters will help establish for FIPS-requiring
procurement agencies that FIPS 140-2 conformance is achieved in,what they
are procuring from you.)

-Kyle H


On Wed, Jul 3, 2019, 11:55 Dipak B  wrote:

> Dear Experts,
>
> Can you please help me with the following question?
>
> My win32 desktop application uses 'libcurl' to interact with web service,
> in order to get my application FIPS 140-2 certified, following is the plan
> which I arrived at after going through the 'User Guide' and 'Security
> Policy' pdfs.
>
> Plan:
> a. After verifying HMAC-SHA1 of openssl-fips-2.0.16.tar.gz, build it to
> generate fipscanister.lib (FOM) as windows static library.
> b. Build libcurl as windows static library using above fipscanister.lib
> c. Link my desktop application with above libcurl.lib after adding
> FIPS_mode_set()
>
> Questions:
> a. On following points a, b,c, can I confirm that my application is FIPS
> 140-2 certified?
> b.  fipscanister.lib is always static library and it can be substituted
> for libssl.lib / ssleay.lib?
>
> Thank you,
> Deepak
>

Re: failing in reproducing .so files

[Kyle Hamilton]

Log into a different terminal window, run top.  Figure out if it's
infinitely looping, if it's getting stuck in a syscall (which sounds likely
-- if it is the case, you need to figure out why, which could be as simple
as a needed fsck or a required kernel update to address a bug), or if you
can kill -9 it when it gets in that state.

You can also try compiling your code on a different machine.  If it fails
there, try a different distribution of your OS (if available).  If these
all fail, it could be something that the OpenSSL team might need to address
in the script.

Good luck.

-Kyle H

On Fri, Jun 14, 2019, 13:13 Giovanni Fontana 
wrote:

> A little bit further...with my problem in trying to build a tailored
> version of openSSL.
>
> If I do make I get at the end of building (trying to make .map file
> before the .so files )
>
>  creating test/libtestutil.a
> ranlib test/libtestutil.a || echo Never mind.
> /usr/bin/perl util/mkdef.pl crypto linux > libcrypto.map
> Error: EVP_PKEY_get0_TUV does not have a number assigned
> Makefile:762: recipe for target 'libcrypto.map' failed
> make[1]: *** [libcrypto.map] Error 25
> make[1]: Leaving directory
> '/home/vm/progetti/OPEN_SSL/OPEN_SSL_QP/openssl-1.1.1b'
> Makefile:172: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
>
> ...where EVP_PKEY_get0_TUV is a proprietary function similar to
> EVP_PKEY_get0_RSA (),
> Usually with a function that *does not have a number assigned *it could
> be ok to do a *make update*, but when I run a *make update* it stopped
> after a small while without concluding the action (and no more commands I
> can run in that terminal window).
> Here the log:
>
> ( cd .; /usr/bin/perl VMS/VMSify-conf.pl \
> < apps/openssl.cnf > apps/openssl-vms.cnf )
> ( cd .; /usr/bin/perl crypto/bn/bn_prime.pl > crypto/bn/bn_prime.h )
> ( cd .; /usr/bin/perl crypto/objects/objects.pl -n \
> crypto/objects/objects.txt \
> crypto/objects/obj_mac.num \
> > crypto/objects/obj_mac.new && \
> mv crypto/objects/obj_mac.new crypto/objects/obj_mac.num )
> ( cd .; /usr/bin/perl crypto/objects/objects.pl \
> crypto/objects/objects.txt \
> crypto/objects/obj_mac.num \
> > include/openssl/obj_mac.h )
> ( cd .; /usr/bin/perl crypto/objects/obj_dat.pl \
> include/openssl/obj_mac.h \
> > crypto/objects/obj_dat.h )
> ( cd .; /usr/bin/perl crypto/objects/objxref.pl \
> crypto/objects/obj_mac.num \
> crypto/objects/obj_xref.txt \
> > crypto/objects/obj_xref.h )
> ( cd .; /usr/bin/perl crypto/conf/keysets.pl \
> > crypto/conf/conf_def.h )
> ( cd .; /usr/bin/perl crypto/asn1/charmap.pl \
> > crypto/asn1/charmap.h )
> ( cd .; /usr/bin/perl fuzz/mkfuzzoids.pl \
> crypto/objects/obj_dat.h \
> > fuzz/oids.txt )
> ( b=`pwd`; set -e; cd .; \
>   /usr/bin/perl util/ck_errf.pl -strict -internal; \
>   /usr/bin/perl -I$b util/mkerr.pl  -internal )
>
>
>
>
> ... as I said the compilation is OK for each file (even the one with
> EVP_PKEY_get0_TUV) , but then no .so libraries. Any suggestions?
>
> Kind regards
> Giovanni Fontana
>
>
>
>
> Il giorno lun 10 giu 2019 alle ore 16:12 Kyle Hamilton 
> ha scritto:
>
>> In the unmodified directory:
>> $ make clean
>> $ make 2>&1 | tee /tmp/openssl-working-build.log
>>
>> In the modified directory:
>> $ make clean
>> $ make 2>&1 | tee /tmp/openssl-broken-build.log
>>
>> $ diff /tmp/openssl-working-build.log /tmp/openssl-broken-build.log |
>> ${PAGER:more}
>>
>> Take note of the differences in output, and use that to determine what
>> broke.  (the '2>&1' syntax redirects stderr to stdout, which is very useful
>> when you need to capture why something is failing.)
>>
>> Good luck.
>>
>> -Kyle H
>>
>> On Mon, Jun 10, 2019, 03:34 Giovanni Fontana <
>> giovanni.fontan...@gmail.com> wrote:
>>
>>> The unmodified version works. As I said, it's sure the issue is on what
>>> I added, but info from the building logs is not sufficient to figure out
>>> what is the issue there. So as result of the building I have just:
>>>
>>>- libcrypto.a
>>>- libssl.a
>>>- libcrypto.map
>>>
>>>
>>> so what is missing are the following files:
>>>
>>>- libssl.map
>>>- libcrypto.so
>>>- libssl.so
>>>
>>>
>>> Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton &l

Re: failing in reproducing .so files

[Kyle Hamilton]

In the unmodified directory:
$ make clean
$ make 2>&1 | tee /tmp/openssl-working-build.log

In the modified directory:
$ make clean
$ make 2>&1 | tee /tmp/openssl-broken-build.log

$ diff /tmp/openssl-working-build.log /tmp/openssl-broken-build.log |
${PAGER:more}

Take note of the differences in output, and use that to determine what
broke.  (the '2>&1' syntax redirects stderr to stdout, which is very useful
when you need to capture why something is failing.)

Good luck.

-Kyle H

On Mon, Jun 10, 2019, 03:34 Giovanni Fontana 
wrote:

> The unmodified version works. As I said, it's sure the issue is on what I
> added, but info from the building logs is not sufficient to figure out what
> is the issue there. So as result of the building I have just:
>
>- libcrypto.a
>- libssl.a
>- libcrypto.map
>
>
> so what is missing are the following files:
>
>- libssl.map
>- libcrypto.so
>    - libssl.so
>
>
> Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton 
> ha scritto:
>
>> Can you try building an unmodified version of the tarball, and see if it
>> has a problem?
>>
>> -Kyle
>>
>> On Sun, Jun 9, 2019, 07:31 Giovanni Fontana 
>> wrote:
>>
>>> Hello Kurt,
>>>
>>>
>>>- it's perl 5, version 26, subversion 1 (v5.26.1) built for
>>>x86_64-linux-gnu-thread-multi
>>>- ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>>>
>>>
>>> I guess is something from what I added since the original OPENSSL I'm
>>> able to build, as well as other intermediate modifications. My issue is
>>> it looks like the log doesn't give so much info and also the *make
>>> update* doesn't complete his task.
>>>
>>> BR
>>> Giovanni
>>>
>>> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx  ha
>>> scritto:
>>>
>>>> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
>>>> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:
>>>>
>>>> There seems to be a problem generating the libcrypto.map file for
>>>> you. What does the file look like? Which perl version are you
>>>> using? Which libc do you use?
>>>>
>>>>
>>>> Kurt
>>>>
>>>>

Re: failing in reproducing .so files

[Kyle Hamilton]

Can you try building an unmodified version of the tarball, and see if it
has a problem?

-Kyle

On Sun, Jun 9, 2019, 07:31 Giovanni Fontana 
wrote:

> Hello Kurt,
>
>
>- it's perl 5, version 26, subversion 1 (v5.26.1) built for
>x86_64-linux-gnu-thread-multi
>- ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>
>
> I guess is something from what I added since the original OPENSSL I'm able
> to build, as well as other intermediate modifications. My issue is it looks
> like the log doesn't give so much info and also the *make update* doesn't
> complete his task.
>
> BR
> Giovanni
>
> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx  ha
> scritto:
>
>> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
>> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:
>>
>> There seems to be a problem generating the libcrypto.map file for
>> you. What does the file look like? Which perl version are you
>> using? Which libc do you use?
>>
>>
>> Kurt
>>
>>

Re: Internal IP Exposed

[Kyle Hamilton]

That's a configuration issue with the servers, not an issue with the
openssl command itself.

There's no information on what the back-end HTTP server software is
being used.  If it were Apache, there would be a ServerName directive
that could change the server's idea of what name it should refer to
itself as.  I don't have information on other server software
configuration.

-Kyle H

On Sun, Mar 24, 2019 at 7:34 PM Abdul Qoyyuum
 wrote:
>
> Hi all,
>
> New to the mailing list and a complete newbie to openssl and the likes. 
> There's a ticket by a client that I'm new at and he claims that there's a 
> security problem with the openssl command to his servers.
>
> Internal IP exposed after running a openssl (version 1.1.0j) connect command:
>
> openssl s_client -connect 103.XX.XXX.XX:10443 -quiet
>
> Where 103.XX.XXX.XX is a Public IP. And after it shows the certificates, 
> typed the following:
>
> GET /images HTTP/1.0
>
> And hit enter twice, the following gets displayed:
>
> HTTP/1.0 301 Moved Permanently
> Date: Mon, 25 Mar 2019 00:10:13 GMT
> Server: -x
> Location: https://10.240.123.1:10443/images/
> Connection: close
> Content-Type: text/html; charset=utf-8
> X-Frame-Options: SAMEORIGIN
> Content-Security-Policy: frame-ancestors 'self'
> X-XSS-Protection: 1; mode=block
> X-Content-Type-Options: nosniff
> Strict-Transport-Security: max-age=28800
>
> 
> 
> 301 Moved Permanently
> 
> Moved Permanently
> The document has moved  HREF="https://10.240.123.1:10443/images/;>here.
> 
> read:errno=0
>
> The 10.240.123.1 is an internal IP and it is exposed by this little method. 
> Although not shown when using curl -kv -O command.
>
> Is there a way to cover up the "Location" or at least the internal IP from 
> being exposed? Thanks.
>
> Sorry if this isn't clear or if this is the wrong place to ask this.
>
> --
> Abdul Qoyyuum Bin Haji Abdul Kadir
> HP No: +673 720 8043

Re: [openssl-users] How to use a specific ip interface while testing TLS/SSL connectivity.

[Kyle Hamilton]

It appears you could create() a socket, bind() it to the interface you
want to use, possibly connect() it, and then pass it to either
BIO_s_connect() or BIO_s_socket() depending on which meets your needs.

-Kyle H

On Sat, Feb 9, 2019 at 7:21 AM Rajinder Pal Singh  wrote:
>
> Thanks Mark for the prompt reply. Absolutely makes sense. Actually, i am on 
> Nonstop HPE servers. There are no internal routing tables or so to say static 
> routes. Environment is different from unix/linux.
>
> From Application perspective, we choose what ip interface to use.
>
> Wondering if we can force the openssl to use specific interface?
>
> Regards.
>
>
>
> On Fri, Feb 8, 2019, 12:26 PM m...@foocrypt.net >
>> Hi Rajinder
>>
>> There shouldn’t be any issues depending on how your host OS is performing 
>> the routing to the network the SSL/TLS endpoint is on.
>>
>> Try a tracerout to the IP to see where it goes, and a telnet IP 80 or 443 to 
>> make sure you can connect to the web server.
>>
>> —
>>
>> Regards,
>>
>> Mark A. Lane
>>
>>
>>
>>
>> On 9 Feb 2019, at 04:20, Rajinder Pal Singh  wrote:
>>
>> Hi,
>>
>> I want to use a specific ip interface (out of several available ethernet 
>> interfaces available on my server) to test TLS/SSL connectivity to a remote 
>> server.
>>
>>
>> Wondering if its possible?
>>
>>
>> Regards,
>> Rajinder.
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] possible C bugs in ecp_nistp521

[Kyle Hamilton]

I would expect that correct results would be provided for all valid
inputs (including those inputs that are not otherwise constrained).
As such, I would class this as a bug in OpenSSL.

-Kyle H

On Mon, Jan 7, 2019 at 7:44 PM Patrick Steuer  wrote:
>
> Dear Bo-Yin Yang,
>
> I looked into your felem_square counterexample:
>
> There is an overflow in the result's least significant 128-bit limb such
> that the computed result is 2^128 smaller than the actual result.
>
> The general problem is the following..
>
> The function's comment says:
> /*-
>   * felem_square sets |out| = |in|^2
>   * On entry:
>   *   in[i] < 2^62
>   * On exit:
>   *   out[i] < 17 * max(in[i]) * max(in[i])
>   */
>
> If you look at the function's code youll notice that given the entry
> assumption, the exit assertion's "less than" should actually be a
> "less than or equal to" for in the case of all in[i]s being equal to say
> x, max(in[i])=x and out[0]=17*x^2.
>
> So out[0] is stored in 128-bits, but for e.g. x=2^62-1, out[0]>2^128.
>
> If its a bug depends on the contexts from which felem_square is called.
> If for some reason its inputs are guaranteed to satisfy some stricter
> entry condition than stated in the above comment (such that there is no
> overflow) things might be alright.
>
> I didnt look at your other examples but id expect something similar.
>
> Best Regards,
>
> Patrick Steuer
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Subject CN and SANs

[Kyle Hamilton]

In order for an Issuer to exist in PKIX, it must be the Subject of another
Certificate (or of a trust anchor).  If a certificate identifies an Issuer,
then the certificate cannot contain an empty sequence of RDNs in the
Subject and still be conformant to PKIX.  This is because the Subject of
the issuing authority certificate needs to be copied (in some way which is
compatible with RFC4518's string preparation rules) into the Issuer of the
certificate that it issues.  This is implied by the path validation
algorithm, and stated explicitly in the last paragraph of RFC5280 section
4.1.2.4 which also refers to RFC5280 section 7.1.

However, PKIX is just a profile of X.509, and alternative approaches to
identifying the Issuer of a certificate exist.  (For self-signed
certificates, Issuer can be an empty sequence of RDNs, but I like to think
of that as a degenerate case that is also explicitly not conformant to PKIX
[RFC5280 section 4.1.2.4 last paragraph].  More importantly, the
IssuerKeyIdentifier can also be set, and matched with the
SubjectKeyIdentifier of another certificate.  This use is contemplated in
RFC 5280 section 4.2.1.2.)

(Note, though, that RFC 5914, "Trust Anchor Format", defines certPath :==
CertPathControls OPTIONAL.  In this case, *only*
IssuerKeyIdentifier/SubjectKeyIdentifier matching can work, and Issuer
otherwise apparently should be blank because the Anchor has no
taName/Subject.  You have to love the inconsistency of the PKIX standards,
yes?)

I haven't ever seen anything claiming that OpenSSL is expected to be
completely and invariably conformant to the PKIX profile.  It's possible
that it could be implied (if SSL or TLS specify that the certificates in
their Certificate records either "SHALL" or "MUST" be PKIX-profiled --
which does not appear to be the case in RFC 8846, which defines TLS 1.3),
but even then I'm not sure it would be appropriate to restrict its utility
in the manner of preventing newer versions from interoperating with
certificates issued by or which worked with older versions that permitted
such degenerate cases.

Merry Christmas (or happy holidays!),

-Kyle H



On Sun, Dec 23, 2018 at 5:33 PM Viktor Dukhovni 
wrote:
>
>
>
> > On Dec 23, 2018, at 6:01 PM, Kyle Hamilton  wrote:
> >
> > You're right, I typoed.  SubjectDN is non-optional.  But it can, as
> > you mentioned, be an empty sequence.
> >
> > But for PKIX purposes, it can't be empty if it's an Issuer (because
> > IssuerDN can't be empty in the certificates that it issues).
>
> That's an odd use of "it", since the issuerDN while also a DN is not
> a subjectDN.  The "it" that is the subjectDN is sometimes legitimately
> empty.  The other "it" that is the issuerDN is supposed to always be
> non-empty, but some self-signed certificates violate that requirement
> with apparent impunity, e.g. nothing in OpenSSL requires a non-empty
> issuer DN in an end-entity self-signed certificate, if it breaks, the
> constraint would be at the application layer.
>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Subject CN and SANs

[Kyle Hamilton]

You're right, I typoed.  SubjectDN is non-optional.  But it can, as
you mentioned, be an empty sequence.

But for PKIX purposes, it can't be empty if it's an Issuer (because
IssuerDN can't be empty in the certificates that it issues).

-Kyle H

On Sun, Dec 23, 2018 at 3:35 PM Viktor Dukhovni
 wrote:
>
>
>
> > On Dec 23, 2018, at 4:29 PM, Kyle Hamilton  wrote:
> >
> > SubjectCN is an operational requirement of X.509, I believe.
>
> You're confusing the DN and the CN.
>
> >  It's not optional in the data structure, at any rate.
>
> The subjectDN is not optional, but it can be empty sequence, and
> is empty for domains whose name exceeds the CN length limit of either
> 63 or 64 characters (can't recall which of the two just now, but that
> is not important).
>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Subject CN and SANs

[Kyle Hamilton]

SubjectCN is an operational requirement of X.509, I believe.  It's not
optional in the data structure, at any rate.

-Kyle H

On Sun, Dec 23, 2018 at 9:22 AM Michael Richardson  wrote:
>
>
> Salz, Rich via openssl-users  wrote:
> > Putting the DNS name in the CN part of the subjectDN has been
> > deprecated for a very long time (more than 10 years), although it
> > is still supported by many existing browsers. New certificates
> > should only use the subjectAltName extension.
>
> Fair enough.
>
> It seems that the "openssl ca" mechanism still seem to want a subjectDN
> defined.  Am I missing some mechanism that would let me omit all of that?  Or
> is a patch needed to kill what seems like a current operational requirement?
>
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT 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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Subject CN and SANs

[Kyle Hamilton]

Does Apache only examine CN=, or does it also check subjectAltNames dNS entries?

-Kyle H

On Sun, Dec 23, 2018 at 3:25 AM Walter H.  wrote:
>
> On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:
> > >  >. New certificates should only use the subjectAltName extension.
> >
> >> Are any CAs actually doing that? I thought they all still included 
> >> subject.CN.
> >
> > Yes, I think commercial CA's still do it.  But that doesn't make my 
> > statement wrong :)
> >
> Apache raises a warning at the following condition
>
> e.g. a virtual Host defines this:
>
> ServerName  www.example.com:443
>
> and the SSL certificate has a CN which does not correspond to
> CN=www.example.com, e.g.  CN=example.com
>
> then the warning looks like this
>
> [Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909:
> www.example.com:443:0 server certificate does NOT include an ID which
> matches the server name
>
> and fills up the logs
>
> Walter
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] AssAccess was passed with no amendments

[Kyle Hamilton]

Getting the key for any given communication from OpenSSL is definitely
doable if you're not using an engine.  If you are using an engine, it may
or may not be even possible.

In any case, maintaining that key once you have it is definitely out of
scope of OpenSSL. As an app developer subject to that law, it is up to you
to figure out a way to keep it available for compliance purposes.

I'm not part of the OpenSSL team, so I have no capacity to make a policy
statement on their behalf.  However, I'm pretty sure that OpenSSL is not
going to alter its API or its library design to make it easier for a
bolt-on AusAssAccess module to be written that directly queries the state
of the library or its structures.

That said, in the past it's been bandied about that an originating software
package subject to the law could encrypt the symmetric key not only to the
intended recipient, but also to a hardcoded compliance key.  A receiving
software package subject to the law would have to modify its receipt
process to store a copy of the symmetric key elsewhere when it first
decrypted a message -- probably also encrypted to a hardcoded compliance
key.

The downside is "what happens when that compliance key is compromised"?
(or, for that matter, if the compliance key is lost.)  And it will be
compromised or lost, someday, some way.  That's the reason so many people
have been against backdoors like this -- the security of the system is
good, but the security of human beings tasked with maintaining the security
of the system is nowhere near as good.

-Kyle H

On Fri, Dec 14, 2018, 18:20 open...@foocrypt.net  Rather than going down the political or policy line, perhaps it may be
> prudent to discuss the technical solutions to testing the engine,
> regardless of the OS it is running on.
>
> How does one validate and test the engines during / after compile to
> ensure their ‘trust’ ?
>
>
>
> > On 15 Dec 2018, at 10:42, Viktor Dukhovni 
> wrote:
> >
> >> On Dec 14, 2018, at 5:42 PM, bmeeke...@buckeye-express.com wrote:
> >>
> >> I simply wanted a clear statement so I can make an informed decision
> whether or not I should use OpenSSL in future projects.  I now have my
> answer.  Thank you.
> >
> > This is not the right forum for that question.  The bill is too
> > new for a policy response to have been considered or agreed.
> >
> > OpenSSL has committers from many countries.  OpenSSH also
> > has an Australian maintainer, have they published a policy?
> >
> > I am sure there are Australian contributors to Linux, NetBSD,
> > FreeBSD, OpenBSD, Android, ...
> >
> > Avoiding all taint from anything touched by Australia will not
> > be easy.
> >
> > --
> >   Viktor.
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

On Fri, Dec 14, 2018, 18:20 open...@foocrypt.net  Rather than going down the political or policy line, perhaps it may be
> prudent to discuss the technical solutions to testing the engine,
> regardless of the OS it is running on.
>
> How does one validate and test the engines during / after compile to
> ensure their ‘trust’ ?
>
>
>
> > On 15 Dec 2018, at 10:42, Viktor Dukhovni 
> wrote:
> >
> >> On Dec 14, 2018, at 5:42 PM, bmeeke...@buckeye-express.com wrote:
> >>
> >> I simply wanted a clear statement so I can make an informed decision
> whether or not I should use OpenSSL in future projects.  I now have my
> answer.  Thank you.
> >
> > This is not the right forum for that question.  The bill is too
> > new for a policy response to have been considered or agreed.
> >
> > OpenSSL has committers from many countries.  OpenSSH also
> > has an Australian maintainer, have they published a policy?
> >
> > I am sure there are Australian contributors to Linux, NetBSD,
> > FreeBSD, OpenBSD, Android, ...
> >
> > Avoiding all taint from anything touched by Australia will not
> > be easy.
> >
> > --
> >   Viktor.
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list

[Kyle Hamilton]

Because only showing the O= is insufficient, you also need to show the
jurisdiction the O= is based in. (In the case of Amazon, it's a Delaware
corporation.)

The fact that browsers are getting tricked into thinking EV doesn't help is
only because their UX designers refuse to allow the information which is
necessary for actual trust to be displayed. It's not the fault of the CAs
or the EV guidelines, it's fully within the hands of the browsers to fix.

But they're worried about "providing free advertising for the CAs" (when I
suggested putting the name of the certifier on the chrome,  so that any
change would raise a flag in the users' mind) or "information overload for
the users" and "insufficient space for other important things" (when I
suggested putting more of the Subject DN on the chrome), even though those
are things that would legitimately put the onus of being tricked fairly on
the user, and off of the browsers which currently don't readily provide the
information.

Regardless, in my view it really doesn't matter. I lost faith in the
browsers being willing to continue to improve things (i.e., work against
the identity homograph arms race) long ago. So now they want to backslide?
I've done my duty to try to convince them to continue to evolve against the
threat landscape. The onus of and blame for their unwillingness to do so is
on them.  Now, I guess we'll only get to see how much of it might stick in
court.

On Sat, Dec 8, 2018, 05:59 Michael Ströder  On 12/7/18 11:44 PM, Michael Wojcik wrote:
> > Homograph attacks combined with phishing would be much cheaper and
> > easier. Get a DV certificate from Let's Encrypt for anazom.com or
> > amazom.com, or any of the Unicode homograph possibilies>
> > Part of the point of EV certificates was supposed to be making the
> > difference in trust visible to end users.
> And how do you avoid such homograph attack on subject DN attribute "O"
> (organization's name) when display the holy EV green sign?
>

By including the jurisdiction the O is organized in, of course.  O=Amazon
Inc,ST=Delaware,C=US.  (That's the point of hierarchical names, after all.
It's to reduce namespace collisions in spaces -- like independent political
entities -- which don't often cooperate together to inhibit problems like
these.)

Interesting note: I could register a corporation named "Bank of America
Corporation" in any state BofA doesn't currently have a presence, to obtain
a potentially EV-valid certificate, and their only recourse might be a
trademark lawsuit.  If I registered it in a foreign nation, they wouldn't
have any recourse at all unless they already had a presence in that
nation.  (Though they might try to convince the feds to prosecute me for
attempted fraud, even if I didn't do anything to actually attempt or
complete a fraud under that name.)  Does this mean that EV is useless? No,
it means that the overarching legal regime enables attacks that
certificates already provide the means to combat -- but only if the
certificate-consuming software properly implements it.  The idea that a
browser thinks EV is useless is worth nothing.  It just means that they
won't invest into this area of security the way they will into preventing
their processes from being hijacked by arbitrary code.

Should they have to invest in this way? I don't know. They took on the role
on their own, either to try to build trust in web-based commerce (where
they succeeded to the tune of tens of billions of dollars in economic
activity every year) or because they had to try to "keep up with the
Joneses" (i.e., Mozilla and Microsoft and Google, who were doing it for the
more altruistic reason). I can't judge whether they "should". I just know
enough to recognize what they "did".


> => EV certs also don't help in this case.
>
> Also in case of amazon.com most users know the pure domain name but not
> the *exact* company name, not to speak of the multitude of names of all
> the subsidiaries.
>

Subsidiary names are relatively irrelevant, as long as the same subsidiary
name shows up when they do the same thing. If it turns out that there's a
need for them to become relevant, a DNS record with the expected Subject DN
could be published, or a sitemap with the expected name of the subsidiary
in question could be made available, or any of a host of other options
could be explored and done. (And let's not forget the homograph attack
enabled by the lack of https-by-default.)

These arguments you make are arguments for letting the nonexistent perfect
be the enemy of the existing good. They're also arguments for not trying to
work toward the hypothetical ideal, and for throwing the baby out with the
bathwater.


> Ciao, Michael.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Question on necessity of SSL_CTX_set_client_CA_list

[Kyle Hamilton]

CAs *do* verify the attributes they certify.  That they're not presented as
such is not the fault of the CAs, but rather of the browsers who insist on
not changing or improving their UI.

The thing is, if I run a website with a forum that I don't ask for money on
and don't want any transactions happening on, why should I have to pay for
the same level of certainty of my identity that a company like Amazon needs?

(Why does Amazon need that much certainty? Well, I could set up wireless
access points around coffee shops in December, point the DNS provided at
those WAPs to my own server and run a fake amazon.com site to capture
account credentials and credit cards. Without EV, that's a plausible
attack. Especially with SSL being not-by-default, someone could type
amazon.com and it can be intercepted without showing any certificate
warning -- which then allows a redirect to a lookalike amazon.com name that
could get certified by something like LetsEncrypt.)

Plus, clouds have had a protocol available for doing queries to certs and
keys held by other parties for several years. Cloudflare developed this
protocol for banks, for whom loss of control of the certificate key is a
reportable event, but who also often need DDoS protection. There's no
reason it can't be extended to other clouds and sites -- unless Cloudflare
patented it and wants royalties, in which case their rent-seeking is
destroying the security of the web by convincing cloud salesmen to say that
EV is too much trouble to deal with and thus should be killed off in the
marketplace.

Demanding that EV be perfect and dropping support for it if it has any
found vulnerability falls into a class of human behavior known as "letting
the perfect be the enemy of the good", which is also known as "cutting off
the nose to spite the face".  It still cuts down on a huge number of
potential attacks, and doing away with it allows those attacks to flourish
again. (Which, by the way, is what organized crime would prefer to permit.)

-Kyle H


On Thu, Dec 6, 2018, 14:07 Blumenthal, Uri - 0553 - MITLL  >> Quoting from Peter Gutmann's "Engineering Security",
> >> section "EV Certificates: PKI-me-Harder"
> >>
> >>  Indeed, cynics would say that this was exactly the problem that
> >>  certificates and CAs were supposed to solve in the first
> place, and
> >>  that “high-assurance” certificates are just a way of charging a
> >>  second time for an existing service.
> >
> >Peter Gutman, for all his talents, dislikes PKI with a vengeance.
> > EV is a standard for OV certificates done right.  Which involves more
> >thorough identity checks, stricter rules for the CAs to follow etc.
> >
> > The real point of EV certificates is to separate CAs that do a good
> >job from those that do a more sloppy job, without completely
> distrusting
> >the mediocre CA operations.
>
> So, a CA that's supposed to validate its customer before issuing a
> certificate, may do a "more sloppy job" if he doesn't cough up some extra
> money.
>
> I think Peter is exactly right here. CA either do their job, or they
> don't. If they agree to certify a set of attributes, they ought to verify
> each one of them.
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath

[Kyle Hamilton]

Wireshark and other packet capture tools can help you determine
exactly what's in the chain sent by the client.  If the self-signed
root isn't being sent, then the "self-signed certificate in
certificate chain" error should never have been sent, and a bug report
on that issue would be appropriate.

If the root is being sent, though, having some idea of what you're
doing when constructing your sessions could help us to figure out why
it is when you didn't intend it to be.

-Kyle H
On Sat, Dec 1, 2018 at 1:47 PM Charles Mills  wrote:
>
> > It was found in the chain of certificates sent by the client to the
> > server for validation
>
> Again, I could be wrong but that is my point. I do not think the client is
> sending a chain of certificates, but rather only one, the CA-signed client
> certificate. (I wrote and configured the client, and generated the
> certificate, and loaded it into the certificate store.)
>
> Charles
>
> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Viktor Dukhovni
> Sent: Saturday, December 1, 2018 12:47 PM
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Self-signed error when using
> SSL_CTX_load_verify_locations CApath
>
> On Sat, Dec 01, 2018 at 12:29:42PM -0800, Charles Mills wrote:
>
> > I could easily be wrong -- you guys know more about certificates than I
> ever
> > will -- but I do not *think* there is any self-signed certificate in this
> > scenario. There should be exactly two certificates in this discussion:
> >
> > 1. The client certificate. It is not self-signed (in the correct sense of
> > the term, as opposed to the erroneous popular sense): it is signed by my
> > "in-house" CA.
> >
> > 2. The CA certificate. Yes, it is a root and self-signed, but you didn't
> > find it, right?
>
> You seem to be stuck on a narrow meaning of the word "found".  The
> self-signed certificate *was* found, but not in the trust-store.
>
> It was found in the chain of certificates sent by the client to the
> server for validation.  That's what the error message is telling
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] What is the need for 0x00 byte prefix in pubkey and prime of a static DH key pair?

[Kyle Hamilton]

The DER (Distinguished Encoding Rules of ASN.1, which can be found in ITU-T
recommendation X.680 and X.681) requirement is that if a particular number
is positive, the highest-order bit can never be set (since the
highest-order bit is always the negative sign indicator). The rules further
explain that the appropriate way to encode a positive integer with the
highest bit set is to add an additional 0x00 byte, making the new most
significant bit into a 0.

This is also why the serial number field in a certificate can be 21 bytes
long, even when implementing PKIX's minimum serial number length of 20
bytes.  Numbers included in an ASN.1-encoded structure aren't ever intended
to be used directly, they're intended to be decoded before the data is
passed back to client code.

I realize this is much more information than you asked, but it might help
to think of it as "it's done this way for compliance with the standards".

-Kyle H

On Thu, Nov 29, 2018, 21:26 M K Saravanan  Hi,
>
> When I create static DH key pair using openssl, why the public key and
> prime contains the prefix 0x00 byte?
>
> For e.g. in 1024 bit key, 128 bytes is enough.
>
> private key properly shows 128 bytes.  But public key and prime shows
> 129 bytes with a 0x00 byte at the beginning.  What is the need for
> this 0x00 byte at the beginning?  i.e. why it is using 129 bytes
> instead of 128?
>
>
> $ openssl version
> OpenSSL 1.1.1  11 Sep 2018
>
> $ openssl dhparam -out mydhp.pem 1024
> [...]
>
> $ openssl genpkey -paramfile ./mydhp.pem -out mydhkey.pem
>
> $ openssl pkey -in ./mydhkey.pem -text -noout
> DH Private-Key: (1024 bit)
> private-key:
> 52:61:87:52:b4:27:5f:c3:cf:ab:2f:20:b4:aa:b7:
> df:c3:87:63:50:d2:06:dd:65:8f:db:55:2e:08:d5:
> 62:44:1a:f5:d8:73:66:fe:a7:c4:43:be:f7:f0:d0:
> ba:4c:bf:f0:70:70:c9:25:92:da:ef:69:01:1a:b9:
> d9:d9:1f:b9:22:a6:84:48:d8:58:a8:a4:9e:7f:85:
> 6b:9e:45:89:07:0c:fb:00:f1:0a:fb:24:10:e4:bb:
> 2b:1c:7d:dc:d1:12:a3:21:5a:9b:8e:bf:9d:33:e8:
> 65:fe:c2:5c:ea:47:fa:00:04:80:cf:85:e1:c6:71:
> 67:4b:7b:71:92:07:59:48
> public-key:
> 00:a0:0d:41:8a:27:55:07:2a:01:dd:a7:e2:86:bb:
> 69:71:86:1d:62:0c:f3:b7:61:78:81:37:6c:a1:d3:
> e8:55:9d:8a:1f:e8:5e:7f:18:00:0f:4e:1d:97:70:
> a0:e7:19:2b:82:69:c3:aa:61:ea:b8:9c:10:36:19:
> e9:b9:13:db:9a:ef:34:bf:10:f7:93:84:5d:a3:b4:
> 58:3a:40:ec:4b:79:06:52:b8:fe:b8:22:0d:f3:f9:
> 33:1e:8e:43:69:bb:77:3d:10:78:c6:65:e8:04:08:
> 96:1e:cc:6c:92:e4:55:f4:2c:d0:3d:b7:5f:58:70:
> cf:fe:a7:5f:23:e3:d9:5e:c4
> prime:
> 00:a2:f4:9d:1c:3f:75:8f:3e:e3:c9:95:09:79:09:
> 16:f2:f0:61:c4:e1:b9:23:22:a3:58:d7:38:7d:06:
> af:57:ad:14:5e:13:bd:71:ed:31:89:cb:65:d6:46:
> 3b:29:57:ad:a9:8e:58:e6:df:c0:37:2f:4f:be:45:
> d7:c8:f1:87:ef:af:65:87:34:4a:7d:78:b8:0b:0b:
> 33:d8:c1:fb:05:9e:ce:9a:27:7e:4a:2a:aa:18:33:
> 35:ea:d0:b0:b7:fa:cb:d1:51:bf:11:98:12:24:be:
> 1d:1c:87:c3:37:ed:0f:b9:53:23:fc:a1:be:75:ed:
> 81:04:e5:6a:b3:83:40:e0:43
> generator: 2 (0x2)
>
>
> with regards,
> Saravanan
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library

[Kyle Hamilton]

I thibk those are all the .asm modules.  If they are, you'll probably want
to Configure with no-asm and rebuild in order to get the C implementations.

-Kyle H

On Wed, Nov 28, 2018, 01:07 Vinay Kumar via openssl-users <
openssl-users@openssl.org wrote:

> Hi All,
>
> The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for binscope
> GSCheck on Windows.
>
> E:\libeay32.dll: error BA2022: libeay32.dll was compiled with the
> following modules for which a language could not be identified. Ensure
> these were compiled with debug information and run BinScope again:
> aes-586.obj
> aesni-x86.obj
> bf-586.obj
> bn-586.obj
> chacha-x86.obj
> cmll-x86.obj
> co-586.obj
> crypt586.obj
> des-586.obj
> ecp_nistz256-x86.obj
> ghash-x86.obj
> md5-586.obj
> poly1305-x86.obj
> rc4-586.obj
> rmd-586.obj
> sha1-586.obj
> sha256-586.obj
> sha512-586.obj
> vpaes-x86.obj
> wp-mmx.obj
> x86-gf2m.obj
> x86-mont.obj
> x86cpuid.obj
>
> Any idea on how to resolve this problem or is it expected behavior.
>
> NOTE:
> 1. Adding /GS flag and enabling debug mode did not resolve the problem.
> 2. The same works fine with 64bit Windows 'libeay32.dll'
> 3. For other OpenSSL library ' libssl32.dll', GSCheck passes for both
> 32bit and 64bit.
>
>
> Regards,
> Vinay
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] updating openssl

[Kyle Hamilton]

Generally, you don't want to replace any system-provided version of OpenSSL
with a different version that has a different ABI. The way you've done so
(without deleting the libraries from the older version) is safe, but don't
remove the system package of openssl-1.0.2. Other packages may link to that
version and stop working if you remove it.

-Kyle H

On Tue, Nov 6, 2018, 14:02 Paul  I configured Openvpn server on ubuntu 16.04 and ubuntu was using a old
> version of openssl 1.0.2 and I was updating openssl to v1.1.1
> Now I've installed the openssl but now unable to mv file installed to ln
> -s /usr/local/ssl/bin/openssl /usr/bin/openssl
> failed to create symbolic link '/usr/bin/openssl': File exists
>
>
>
> but then when I use openssl version
>
>  /usr/bin/openssl: No such file or directory
>
>
> how can I correct this?
>
> Paul
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> This message contains confidential information and is intended only for the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. If you are not the intended recipient
> you are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this information is strictly
> prohibited.--
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Wildcard: how are they correct?

[Kyle Hamilton]

If subjectAltName exists, CN= is not evaluated.  All the given
examples should work.  (The only exceptions are validators that
haven't been current for more than 20 years.)  None of the examples is
correct.  CN= should not even be included in the certificate.  If it
is, (d) is the closest to correct, if "hello world" is replaced by
something meaningful to the identification or naming of the subject.

-Kyle H
On Tue, Oct 9, 2018 at 11:18 PM Walter H.  wrote:
>
> Hello,
>
> which of these possibilities is the correct one?
>
> (a)  CN=*.example.com
>  and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (b)  CN=example.com
>  and subjectAltName = DNS:example.com, DNS:*.example.com
>
> (c)  CN=example.com
>  and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (d)  CN=hello world
>  and subjectAltName = DNS:example.com, DNS:*.example.com
>
> Thanks,
> Walter
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Limit the number of AES-GCM keys allowed in TLS

[Kyle Hamilton]

...and once again FIPS screws those who don't want to adhere to its
mandates (which everyone in the know has always stated simply reduces
security by requiring the use of less-secure ciphers and implementations,
without allowing patches or modifications to deal with newly-discovered
classes of attacks without requiring a complete new validation procedure).

Also, I fear that I am likely to be viewed as "overly paranoid" here, by
reminding everyone that Oracle exists because CIA wanted a way to avoid
paying IBM more money.  They have maintained their national-security roots
("Trusted Oracle", anyone?), and both US and Australia are members of the
Five Eyes coalition; there's no reason that governments wouldn't lean on
their assets which hire contributors to OpenSSL to reduce the putative
security level that OpenSSL could provide, via platitudes of the form "the
check will be cheaper".  (It was in the Snowden docs, after all, that the
US government has wealened encryption by sabotaging standardization efforts
and open-source particopation.  I have no doubt that governments within
Five Eyes want to decrease the number of keys they have to crack in traffic
that they don't already know the profile of.)

I really think that the checks should be conditional on FIPS mode or
setting an option flag (for those national standards that don't have a
validation effort associated with them).

-Kyle H

On Sun, Sep 16, 2018, 14:23 Paul Dale  wrote:

> There is nothing S390 specific in this, it is a requirement to use GCM
> based ciphers for TLS when running in a FIPS validated environment.  The
> check will be cheaper than trying to avoid it by conditioning on FIPS mode
> -- hence it’s unconditional.
>
>
>
>
>
> Pauli
>
> --
>
> Oracle
>
> Dr Paul Dale | Cryptographer | Network Security & Encryption
>
> Phone +61 7 3031 7217
>
> Oracle Australia
>
>
>
> *From:* Dmitry Belyavsky [mailto:beld...@gmail.com]
> *Sent:* Friday, 14 September 2018 8:41 PM
> *To:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] Limit the number of AES-GCM keys allowed
> in TLS
>
>
>
> Hello,
>
>
>
> Sorry, I've just found similar checks in all _CGM functions.
>
>
>
> On Fri, Sep 14, 2018 at 1:30 PM Dmitry Belyavsky 
> wrote:
>
> Dear Paul,
>
>
>
> Could you please clarify?
>
> The code seems to be related to s390 platform. Do I miss something?
>
>
>
> On Thu, Sep 13, 2018 at 1:55 AM Paul Dale  wrote:
>
> I wasn’t aware of other national standards requiring a similar check.
>
>
>
> I made the change in the AES-GCM code because FIPS demands the check be
> inside the FIPS boundary.  I’d have preferred to make it in the TLS layer,
> but that mustn’t be inside the FIPS boundary.  My understanding is that TLS
> catches this case earlier and thus the test can never pass.
>
>
>
> I don’t think dropping the check down into the algorithm implementations
> makes sense.  A more generic mechanism at the EVP would.
>
>
>
>
>
>
>
> Pauli
>
> --
>
> Oracle
>
> Dr Paul Dale | Cryptographer | Network Security & Encryption
>
> Phone +61 7 3031 7217
>
> Oracle Australia
>
>
>
> *From:* Dmitry Belyavsky [mailto:beld...@gmail.com]
> *Sent:* Wednesday, 12 September 2018 7:02 PM
> *To:* openssl-users@openssl.org
> *Subject:* [openssl-users] Limit the number of AES-GCM keys allowed in TLS
>
>
>
> Hello,
>
>
>
> The issue https://github.com/openssl/openssl/pull/7129 has introduced a
> possibility to limit the amount of TLS records processed without key
> changing as required by FIPS.
>
>
>
> We in Russia have limitations with the same semantics applicable to
> Russian GOST TLS ciphersuites (
> https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suites/) so
> I think that this mechanism is very useful.
>
>
>
> The current implementation is done at EVP level, and it seems suboptimal
> because of the following reasons:
>
> - If the AES implementation is provided via engine, not by OpenSSL itself,
> the limitation can be avoided
>
> - the limitation has been made too generic
>
> - the implementation seems to be AEAD-specific.
>
>
>
> So does not it make sense to provide this limitation at least at the
> ciphersuite level? It can provide more straightforward way to manage such
> limitations.
>
>
> Thank you!
>
>
>
> --
>
> SY, Dmitry Belyavsky
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] X25519 - why openssl shows server temp key as 253 bits?

[Kyle Hamilton]

Probably because the definition of X25519 requires that bits 0, 1, and 2 of
the first byte of the private key are set to 0 before being used, and
OpenSSL counts the number of bits including the highest-order set bit.
(Really, there's an additional 2 bits that are also set to known values:
bit 6 of the last byte is set, and bit 7 of the last byte is cleared.  In
my view, this actually reduces the necessary brute-force search space from
256 bits to 251 bits. However, literally any 32-byte string can be used as
a public key.  Apparently, djb views this as sufficient to call it a
256-bit strength function.)

For the specification, please see the subsection entitled "Responsibilities
of the User" in section 3 of https://cr.yp.to/ecdh/curve25519-20060209.pdf .

-Kyle H





On Mon, Sep 3, 2018, 22:29 M K Saravanan  wrote:

> Hi,
>
> When using openssl with X25519, why it shows the server temp key as 253
> bits?
>
> Example:
>
> ---
> No client certificate CA names sent
> Peer signing digest: SHA256
> Peer signature type: RSA
> Server Temp Key: X25519, 253 bits
> ---
>
> I thought Curve25519 is using 256 bit keys.
>
> Why 253 instead of 256?
>
> with regards,
> Saravanan
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Deployment

[Kyle Hamilton]

Generally, you *really* do not want to replace the vendor-provided
version.  Vendors often alter things to be more compatible with their
ABIs, which are the binary interfaces that other programs use to link
to the vendor-provided libraries.

If you find you actually do want to, it's best to figure out how to
get the source code of the vendor package you currently have
installed, determine what patches were applied by the vendor, then
apply those patches to the newer library version, and rebuild.  If you
have a command that can build a system installation package from
source code and maybe patches that you provide, that would be even
better.  If you can do that, you can then install the new package you
just compiled as an upgrade.

If you can't build a new system package, you have to figure out what
files were installed by the vendor's openssl package, and back them
up.  Then, you need to find the associated versions built by you, and
place them by hand.

And if you can't get the source code to the system version, you're
going to have to wing it.  On a machine that you can make mistakes on
without inconveniencing other users, do the same thing as if you
couldn't build a new system package.  Then, after placing everything,
you would generally (on most Linuxes, depending how recent their ld.so
package is) run 'ldconfig' to rebuild the symbolic links to what they
should be.  But here's the scary part: you then need to shut the
machine down, bring it back up, and attempt to connect to it via ssh
or something.  You will need to test *every* package that you use that
links to openssl,
in case there were any ABI incompatibilities introduced by the vendor.
If there are any problems, you'll need to contact the vendor for an
updated version.  This may require paying additional support fees.

Good luck!

-Kyle H

On Mon, Jul 16, 2018 at 1:36 AM, Dean Warren  wrote:
> Built openssl 0.9.8za with no problems on SUSE Linux Enterprise Server.
>
> Just followed
> https://wiki.openssl.org/index.php/Compilation_and_Installation?
>
> Works a treat - thanks.
>
>
>
> However on sudo make install the new version doesn’t replace the system
> installed version (obviously this may be different per system).
>
>
>
> How to make sudo make install overwrite my system version?
>
> Is this a parameter within ./Configure?
>
> And/or is it also OK to just replace original bins with symbolic links to
> new built openssl binary and library (are there others?)?
>
>
>
> Thanks in advance
>
> Dean Warren
> Solutions Architect – Space Division
>
> SCISYS UK Limited
> T:  +44 (0)117 916 5182
> F:  +44 (0)117 916 5299
> E:  dean.war...@scisys.co.uk
> http://www.scisys.co.uk
>
>
>
>
>
> SCISYS UK Limited. Registered in England and Wales No. 4373530.
> Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.
>
> Before printing, please think about the environment.
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] MTLS verification fails

[Kyle Hamilton]

> #$ openssl s_server -key privkey.pem -cert server.pem  -accept 8446 -verify 
> ca.pem

Change the '-verify' to '-CAfile' and it might work.

-Kyle H

On Sun, Mar 4, 2018 at 9:58 PM, salil GK  wrote:
>
> #$ openssl s_client -cert tomcat.pem  -key tomcat_priv.pem  -CAfile
> ca.pem -connect lrc1.cisco.com:8446
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Has client validated successfully?

[Kyle Hamilton]

No, you cannot query the SSL layer to know if the client validated the
certificate.  SSL/TLS don't provide any means of querying the remote
side.

Here's how the workflow works:

1) client doesn't trust certificate, doesn't override distrust:
connection closes with fatal unknown_ca or expired_certificate alert.
2) client doesn't trust certificate, does override distrust:
connection continues.  No way to query if distrust was overridden.
3) client does trust certificate, no need to override: connection
continues.  No way to query if distrust was overridden.

There's no way for the server to know if the client trusts the
certificate, or if the client overrode the distrust.

There's generally also no way for Javascript on the client to know
this, either.  However, because this is a list about OpenSSL (and not
about any given application of OpenSSL, i.e. the web) it's not the
best place to ask about how to do this on the web.

Certificate chain updates (to avoid chain expiration) by the server
are expected to be done unilaterally, by the server operator.

If different certificate chains need to be provided to different
clients, the different clients can request different hostnames (via
the Server Name Indication extension) so the server can decide which
certificate chain to present.

As much as it sucks, this is the only server certificate selection
mechanism that exists in SSL/TLS.

-Kyle H

On Tue, Feb 20, 2018 at 9:34 AM, J Decker <d3c...@gmail.com> wrote:
>
>
> On Tue, Feb 13, 2018 at 9:33 AM, Emmanuel Deloget <log...@free.fr> wrote:
>>
>> Hello,
>>
>> On Tue, Feb 13, 2018 at 7:14 AM, Kyle Hamilton <aerow...@gmail.com> wrote:
>>
>> > The only thing that the server can know is whether the client has
>> > terminated the connection with a fatal alert.  If the client validates
>> > presented cert chains, then its continuation with the connection means
>> > that it passed validation.  If the client does not, or ignores any
>> > given error, then it doesn't mean that it passed validation.
>> >
>> > In other words, you can only know if the client's applied policy
>> > allows the connection to continue.  You cannot know if the policy that
>> > was applied was specifically related to the certificate chain
>> > presented.
>> >
>> > -Kyle H
>> >
>> > On Mon, Feb 12, 2018 at 10:06 PM, J Decker <d3c...@gmail.com> wrote:
>> > > Is there a way for a server to know if the client verified the cert
>> > > chain
>> > > successfully or not?
>> >
>>
>> From a security PoV, that doesn't help much. One can build a malicious
>> version of openvpn that will tell you "everything's ok" (or "it failed!",
>> depending of its goal). The server should not make any decision w.r.t. the
>> client state (that's more or less what is implied by Kyle's answer ; I
>> just
>> wanted to stress it).
>>
>
> Yes that is true however here's the scenario.
> Client does a verification and passes or fails, and via the SSL layer I can
> query if the client validated the certificate.
> If it failed, provide a option for the client to get a renewed certificate
> for verification.  If success, no action.
> If an actor lies in this scenario he answers
> lies *yes* and didn't, don't give him a means to actually verify. *noop*
> lies *no* but did, then give him the root cert he already has *noop*
>
> so I don't have to trust the reply I'm willing to give him the right
> root.
>
>>
>> BR,
>>
>> -- Emmanuel Deloget
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Has client validated successfully?

[Kyle Hamilton]

The only thing that the server can know is whether the client has
terminated the connection with a fatal alert.  If the client validates
presented cert chains, then its continuation with the connection means
that it passed validation.  If the client does not, or ignores any
given error, then it doesn't mean that it passed validation.

In other words, you can only know if the client's applied policy
allows the connection to continue.  You cannot know if the policy that
was applied was specifically related to the certificate chain
presented.

-Kyle H

On Mon, Feb 12, 2018 at 10:06 PM, J Decker  wrote:
> Is there a way for a server to know if the client verified the cert chain
> successfully or not?
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] mail encryption with ecdsa cert

[Kyle Hamilton]

On the algorithmic side of things, the ECDSA algorithm cannot encrypt.
It is signing-only.

In order to use Elliptical Curves to encrypt, you would have to use
the "Elliptical Curve Diffie-Hellman" algorithm to perform a key
agreement.  This requires that both the sender and the recipient have
EC keys which are marked in their certificates as being for the
purpose "keyAgreement".

Your command line only specifies the recipient certificate, not the
sending certificate.  You can't do an ecdh_kdf_md:sha256 operation
without the sender's certificate and private key.

I hope this helps!

-Kyle H



On Fri, Jan 26, 2018 at 7:13 AM, clou  wrote:
> openssl 1.1.0.f
> ecdsa 512 certificate
>
> openssl cms -sign works perfect and sending an email.
>
> For encryption and sending an email I just get an email with an attachment
> smime.p7m.
>
> I use the following encryption command
>
> openssl cms -encrypt \
> -recip cert.pem \
> -subject 'openssl encrypt' \
> -to email \
> -from email \
> -in msg.txt \
> -keyopt ecdh_kdf_md:sha256 \
> | \
> sendmail email
>
>
> Any idea how I need do encrypt (or encrypt and sign) in order to get a
> proper email?
>
> Thanks a lot!
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] SSL Cert serial number non-uniqueness impact

[Kyle Hamilton]

It's important to note that NSS-based applications (such as Firefox)
will actually categorically refuse to connect to a site with an
Issuer/serial collision with another certificate it has seen before.

So yes, it can cause some applications to fail their SSL connections.

-Kyle H

On Tue, Jan 16, 2018 at 1:26 AM, Wouter Verhelst
 wrote:
> On 14/01/2018 12:07, pratyush parimal wrote:
>> Hi everyone,
>>
>> I read  from several sources that the serial number of a cert MUST be
>> unique within a CA. But could someone explain what would happen if the
>> serial number was not unique?
>
> The certificate itself will continue to work (the signature will be
> valid), but requesting status on the certificate (e.g., through OCSP or
> by doing a lookup in a CRL) will not work as expected as those use the
> serial number as an identifier.
>
>> Would it cause SSL connections to fail in some manner?
> No, but if the peer wants to request information on the used certificate
> from the CA to verify whether the certificate is still valid, it may end
> up receiving information about the wrong certificate.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Lattice Ciphers

[Kyle Hamilton]

On Mon, Dec 18, 2017 at 9:59 AM, Colony.three via openssl-users
 wrote:
>
> Hear about the HP keylogging case recently?  Do you think a keylogger is
> actually used in testing of a keyboard driver, in practice?

Yes.

More specifically, it's used to ensure that the scancodes that should
be detected when a particular key is hit or released are actually
detected when that key is hit or released.  It's also useful for
identifying how a particular keyboard has failed, to see which
scancodes aren't being transmitted properly.

That said, it's not something that should be left in a production
driver.  It's more suited for a development/diagnostics station than a
general-purpose system.

(Eeesh.  And my friends call *me* "paranoid".)

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

Re: [openssl-users] Lattice Ciphers

[Kyle Hamilton]

On Sun, Dec 17, 2017 at 3:58 PM, Salz, Rich via openssl-users
 wrote:

>> If you follow Schnieder, elliptic curve is not an option.
>
> That’s interesting, you have a reference for that?

I'm guessing OP's referring to "Applied Cryptography, 2nd Edition".
There was one page on elliptical curve cryptography, and it didn't
give any real information on what it was, what problem it uses (the
discrete logarithm problem), how it's used, or how DH is adapted to
use it.  The book was pretty much entirely against software patents,
and because ECC had been freshly patented it seemed to be much more
scary about the topic than it should have been.

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

Re: [openssl-users] SSL alert number 48

[Kyle Hamilton]

SSL alert number 48 is specified in the documents that define SSL/TLS.
It is the code for "unknown_ca", which means that verification failed
because it didn't get set up with the correct CA to verify against.
You might wish to look up SSL_CTX_load_verify_locations(3).  There may
also be other API calls which can load the context with certificates
to verify against.

You can get a list of the alert numbers from RFC 5246, available from
(among other places) https://www.ietf.org/rfc/rfc5246.txt (also
available as a PDF from https://www.ietf.org/rfc/rfc5246.txt.pdf).

-Kyle H

On Mon, Dec 4, 2017 at 12:10 AM,   wrote:
> Hi ,
>
> Please see in attach the files that I'm using.
> I generate the certificates with the following commands:
>
> ## Create CA
> openssl genrsa -out ca.key 4096
> openssl req -new -x509 -days 365 -key ca.key -out ca.crt
> openssl x509 -in ca.crt -out ca.pem -outform PEM
>
> ## Create the Server Key and CSR
> openssl genrsa -out server.key 4096
> openssl req -new -key server.key -out server.csr
> openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key
> -set_serial 01 -out server.crt
> openssl x509 -in server.crt -out server.pem -outform PEM
>
> ## Create the Client Key and CSR
> openssl genrsa -out client.key 4096
> openssl req -new -key client.key -out client.csr
> openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key
> -set_serial 01 -out client.crt
> openssl x509 -in client.crt -out client.pem -outform PEM
>
>
> I left the default value of each question that openssl ask when it's
> creating the certificates like Country, City, CN, etc. Like this way:
>>
>> openssl req -new -key server.key -out server.csr
>>
>> You are about to be asked to enter information that will be incorporated
>>
>> into your certificate request.
>>
>> What you are about to enter is what is called a Distinguished Name or a
>> DN.
>>
>> There are quite a few fields but you can leave some blank
>>
>> For some fields there will be a default value,
>>
>> If you enter '.', the field will be left blank.
>>
>> -
>>
>> Country Name (2 letter code) [AU]:
>>
>> State or Province Name (full name) [Some-State]:
>>
>> Locality Name (eg, city) []:
>>
>> Organization Name (eg, company) [Internet Widgits Pty Ltd]:
>>
>> Organizational Unit Name (eg, section) []:
>>
>> Common Name (e.g. server FQDN or YOUR name) []:
>>
>> Email Address []:
>>
>> Please enter the following 'extra' attributes
>>
>> to be sent with your certificate request
>>
>> A challenge password []:
>>
>> An optional company name []:
>
>
> Thanks.
> Kind regards.
>
>
> On Thu, Nov 30, 2017 at 2:45 PM, Jan Just Keijser  wrote:
>>
>> Hi,
>>
>> On 29/11/17 14:37, wizard2...@gmail.com wrote:
>>
>> Hi JJK,
>>
>> I test you function and I've got this result:
>>>
>>> ok = 0
>>> cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
>>> ok = 1
>>> cert DN: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
>>
>>
>> Why I see this 2 time?
>> When I create the certificates I didn't fill with any special information,
>> just type enter in every question that is made. Did you think this could
>> cause this issue?
>>
>>
>> what you should have seen is the certificate stack, starting with the CA,
>> and then the client cert, e.g.
>>
>> Connection accept...
>> ok = 1
>> cert DN: /C=US/O=Cookbook 2.4/CN=Cookbook 2.4
>> CA/emailAddress=open...@example.com
>> ok = 1
>> cert DN: /C=US/O=Cookbook 2.4/CN=client1
>>
>>
>> so I suspect that your ca.crt on the server side is not specified
>> correctly.
>> You may also send me your ca.crt, server.{crt,key} and client.{crt,key}
>> files privately, and I will run the same test using your set of
>> certificates.
>>
>> HTH,
>>
>> JJK
>>
>>
>>
>>
>> On Wed, Nov 29, 2017 at 8:56 AM, Jan Just Keijser 
>> wrote:
>>>
>>> Hi,
>>>
>>> On 28/11/17 11:03, wizard2...@gmail.com wrote:
>>>
>>> Hi there.
>>>
>>> I guess my problem is really related to verify callback on
>>> SSL_CTX_set_verify function.
>>> I just add to my code a dummy callback returning 1 and everything works
>>> properly.
>>>

 int verify_callback (int ok, X509_STORE_CTX *ctx);
 int verify_callback (int ok, X509_STORE_CTX *ctx)
 {
 printf("Verification callback OK!\n");
 return 1;
 }
 ...
 SSL_CTX_set_verify(ssl_server_ctx, SSL_VERIFY_PEER |
 SSL_VERIFY_FAIL_IF_NO_PEER_CERT, dtls_verify_callback);
 ...
>>>
>>>
>>> The problem is that error don't tell much information about what's really
>>> going on or what's really missing.
>>> Thanks for your help.
>>>
>>> Now you've effectively disabled all security :)
>>>
>>> Try adding this to the verify_callback
>>>
>>>
>>> static int verify_callback(int ok, X509_STORE_CTX *ctx)
>>> {
>>> X509   *cert = NULL;
>>> char   *cert_DN = NULL;
>>>
>>> printf("ok = %d\n", ok);
>>> cert= X509_STORE_CTX_get_current_cert(ctx);
>>> cert_DN = X509_NAME_oneline( X509_get_subject_name( 

Re: [openssl-users] Serial Number with OpenSSL

[Kyle Hamilton]

4Q? 8X? 1Z?

Those are not octets that can show up in serial numbers.

-Kyle H

On Fri, Dec 1, 2017 at 2:21 PM, FOURES TOM  wrote:
> Hello,
>
> When I see SSL certificates, their serial number is like this :
> 0A:8D:9A:4Q:8X:1A:0B:88:18:1Z
>
> So, how could I set my serial file (with serial.old) for to obtain User
> Certificates with this serial using my openssl.cnf file?
>
>
> Thank you for your help!
>
> Have a nice day.
>
> Aris
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to get SNI info from s_client debug logs?

[Kyle Hamilton]

The -servername [host] is what causes the SNI extension to be sent.  I
don't think its sending is put into the debug output. Do you really need it
there?

I'm pretty certain that s_server outputs it in debug output.

-Kyle H

On Nov 26, 2017 18:59, "John Jiang"  wrote:

> Hi,
> The following is my OpenSSL version info,
> OpenSSL 1.1.0f  25 May 2017
>
> I supposed the below command can give me some SNI info, but nothing was
> found.
> openssl s_client -debug -tlsextdebug -msg -connect  -servername
>  < /dev/null | grep "server name"
> But I found SNI extension with Wireshark while running the above command.
>
> Is it possible get SNI info with s_client?
> Thanks!
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] alert number 46:

[Kyle Hamilton]

Use a publicly-trusted certification authority, such as Let's Encrypt.
The problem is from the remote side (it's sending the alert that it
does not recognize your certificate issuer).

-Kyle H

On Sun, Nov 12, 2017 at 7:47 AM, Simon Matthews
 wrote:
> On Sun, Nov 12, 2017 at 4:55 AM, Jan Just Keijser  wrote:
>> Hi,
>>
>> On 12/11/17 05:39, Simon Matthews wrote:
>>>
>>> I have generated a new certificate for my CentOS 6/postfix server, and
>>> it seems to work with most clients, but when I try to send email using
>>> tls from my Android device, it always fails.
>>>
>>> In my postfix log, I see:
>>>
>>> warning: TLS library problem: 13671:error:14094416:SSL
>>> routines:SSL3_READ_BYTES:sslv3 alert certificate
>>> unknown:s3_pkt.c:1275:SSL alert number 46:
>>>
>>> I get the same message when using the same new certificate with
>>> dovecot, so I don't think it is a postfix issue.
>>>
>>> To generate the certificate, I used the following commands:
>>>
>>> openssl genrsa -out MatthewsCA2017.key 2048
>>> openssl genrsa -des3 -out MatthewsCA2017.key 2048
>>> openssl req -x509 -new -nodes -key MatthewsCA2017.key -sha256 -days
>>> 3000 -out MatthewsCA2017.pem
>>> openssl genrsa -out smtp.matthews-family.org.uk.key 2048
>>> openssl req -new -key smtp.matthews-family.org.uk.key -out
>>> smtp.matthews-family.org.uk.csr
>>> openssl x509 -req -in smtp.matthews-family.org.uk.csr -CA
>>> MatthewsCA2017.pem -CAkey MatthewsCA2017.key -CAcreateserial -out
>>> smtp.matthews-family.org.uk.crt -days 3000 -sha256
>>>
>>> Any ideas on what might be wrong?
>>>
>>
>> you seem to have generated your own (new) CA and server certificate; is this
>> CA (public) cert installed in postfix correctly. More importantly, is this
>> new CA distributed to all devices?
>> An alert 46 usually hints at SSL3_AD_CERTIFICATE_UNKNOWN
>
> In my Android device, I am using the option "TLS (Accept all
> certificates)" which was working with my prior certificate. I built a
> new CA and certificate because Microsoft/Hotmail would not send email
> to my server because of the use of MD5 in the certificate chain.
>
> In the postfix main.cf, I have:
> smtpd_tls_CAfile =  /etc/ssl/MatthewsCA2017.pem
>
> The file exists:
> # ls /etc/ssl/MatthewsCA2017.pem
> /etc/ssl/MatthewsCA2017.pem
>
> This is CentOS 6 VM.
>
> Is there anything else I should do to install the certificates? I
> notice that the dovecot configuration doesn't explicitly define the CA
> certificate location, so perhaps I have missed something?
>
> Simon
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Troubleshooting SSL connections

[Kyle Hamilton]

What kind of stateful packet inspection are the NATs doing?

Can you run packet captures on each network that's being translated?

-Kyle H

On Thu, Nov 2, 2017 at 4:23 PM, Paul Greene  wrote:
> Yes. I've made captures on both - the production client that I manage and
> the test client I have at home.
> On the production client, the conversation lasts only 8 packets - the
> initial 3 way handshake, my client sends a PUSH packet, gets an ACK from the
> upstream, and then the upstream sends a FIN packet and closes the
> connection. The actual error message you see from the commandline is what I
> posted above.
> On the test client, after the PUSH packet is sent to the upstream server, it
> starts a conversation, and they continue the conversation until I did a
> CTRL-C.
>
> Paul
>
> On Thu, Nov 2, 2017 at 11:00 AM, Salz, Rich via openssl-users
>  wrote:
>>
>> Have you thought of putting a packet-capture on, say, the client side and
>> then viewing it?
>>
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Generating CSR based on an x25519 public key

[Kyle Hamilton]

Out of curiosity, what are the algorithm identifiers for X25519 and Ed25519?

-Kyle H

On Mon, Oct 23, 2017 at 3:24 PM, Jakob Bohm  wrote:
> On 21/10/2017 15:38, Codarren Velvindron wrote:
>>
>> https://tls13.crypto.mozilla.org is using : The connection to this site is
>> encrypted and authenticated using a strong protocol (TLS 1.3), a strong key
>> exchange (X25519), and a strong cipher (AES_128_GCM).
>>
>> Using openssl standard tools is it possible to generate a CSR through
>> Ed25519 ?
>>
>
>
> If you look further into this test page, at least with my
> browser, it uses x25519 with a regular RSA certificate from
> Let's encrypt.  I don't know if they use a different
> certificate with other browsers based on checking some TLS
> extensions etc.
>
> The x25519 public key has no certificate, it is randomly
> generated for each connection and signed with the RSA key
> from the certificate.
>
>
> 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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

[Kyle Hamilton]

Important caveat: SSL_read() and SSL_write() don't directly return
SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. Those values are returned
by SSL_get_error().

I apologize for the misstatement.

-Kyle H


On Sun, Oct 8, 2017 at 5:58 PM, Kyle Hamilton <aerow...@gmail.com> wrote:
> Do you have a reference to what should be done instead?
>
> My understanding of what happens with blocking sockets is that
> SSL_read() will return SSL_ERROR_WANT_READ if it needs additional data
> read from a socket that doesn't have it available (and will return
> SSL_ERROR_WANT_WRITE if it needs to write for a handful of reasons,
> but can't).  I had thought that the appropriate response would be to
> add that descriptor to the appropriate set to query on the next call
> to select(), and then call the same function with the same parameters
> so the library can advance its state machine.
>
> write() and read() have the means to tell you how much data was
> written or read, and that's what you're supposed to use to keep
> blocking descriptors from hanging your application, I thought.
>
> -Kyle H
>
>
> On Sun, Oct 8, 2017 at 6:48 AM, Thomas J. Hruska
> <shineli...@shininglightpro.com> wrote:
>> On 10/8/2017 4:17 AM, Kyle Hamilton wrote:
>>>
>>> The way to handle this situation is simply to never enter SSL_read() if
>>> there isn't anything to read on the socket.  select() or pselect() are
>>> your
>>> friends, here, because they'll tell you if there's data to read from the
>>> underlying file descriptor.
>>>
>>> I hope this helps!
>>>
>>> -Kyle H
>>
>>
>> Since the OP is talking about blocking sockets, I'm going to reiterate
>> something someone pointed out to me on this very list many years ago and
>> save someone a LOT of headaches:
>>
>> select() should NEVER, EVER be used for blocking sockets.
>>
>>
>> Just because select() returns any given descriptor doesn't mean that a call
>> won't still block when working with blocking sockets.  select() is for
>> non-blocking descriptors ONLY.  The amount of extra code involved for
>> handling non-blocking sockets is actually quite minimal when a state engine
>> is adopted.
>>
>> I'd love to see select() implementations raise an exception and kill the
>> whole application off when passing it a blocking descriptor.  Then we would
>> discover how much broken software is floating around out there. Since I
>> still see lots of recommendations for using select() with blocking
>> descriptors and all of the official system-level documentation for select()
>> is silent on this issue, I'm guessing a lot.
>>
>> --
>> Thomas Hruska
>> Shining Light Productions
>>
>> Home of BMP2AVI and Win32 OpenSSL.
>> http://www.slproweb.com/
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

[Kyle Hamilton]

Do you have a reference to what should be done instead?

My understanding of what happens with blocking sockets is that
SSL_read() will return SSL_ERROR_WANT_READ if it needs additional data
read from a socket that doesn't have it available (and will return
SSL_ERROR_WANT_WRITE if it needs to write for a handful of reasons,
but can't).  I had thought that the appropriate response would be to
add that descriptor to the appropriate set to query on the next call
to select(), and then call the same function with the same parameters
so the library can advance its state machine.

write() and read() have the means to tell you how much data was
written or read, and that's what you're supposed to use to keep
blocking descriptors from hanging your application, I thought.

-Kyle H


On Sun, Oct 8, 2017 at 6:48 AM, Thomas J. Hruska
<shineli...@shininglightpro.com> wrote:
> On 10/8/2017 4:17 AM, Kyle Hamilton wrote:
>>
>> The way to handle this situation is simply to never enter SSL_read() if
>> there isn't anything to read on the socket.  select() or pselect() are
>> your
>> friends, here, because they'll tell you if there's data to read from the
>> underlying file descriptor.
>>
>> I hope this helps!
>>
>> -Kyle H
>
>
> Since the OP is talking about blocking sockets, I'm going to reiterate
> something someone pointed out to me on this very list many years ago and
> save someone a LOT of headaches:
>
> select() should NEVER, EVER be used for blocking sockets.
>
>
> Just because select() returns any given descriptor doesn't mean that a call
> won't still block when working with blocking sockets.  select() is for
> non-blocking descriptors ONLY.  The amount of extra code involved for
> handling non-blocking sockets is actually quite minimal when a state engine
> is adopted.
>
> I'd love to see select() implementations raise an exception and kill the
> whole application off when passing it a blocking descriptor.  Then we would
> discover how much broken software is floating around out there. Since I
> still see lots of recommendations for using select() with blocking
> descriptors and all of the official system-level documentation for select()
> is silent on this issue, I'm guessing a lot.
>
> --
> Thomas Hruska
> Shining Light Productions
>
> Home of BMP2AVI and Win32 OpenSSL.
> http://www.slproweb.com/
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Graceful shutdown of TLS connection for blocking sockets

[Kyle Hamilton]

The way to handle this situation is simply to never enter SSL_read() if
there isn't anything to read on the socket.  select() or pselect() are your
friends, here, because they'll tell you if there's data to read from the
underlying file descriptor.

I hope this helps!

-Kyle H

On Oct 5, 2017 02:58, "mahesh gs"  wrote:

> Hi All,
>
> I have query regarding the SSL_read on blocking socket. How to come out of
> blocking SSL_read when we have to close the connection ?
>
> As per the documentation SSL_read will only return if there is any data or
> an error occurred.
>
>  "If the underlying BIO is *blocking*, SSL_read() will only return, *once
> the read operation has been finished or an error occurred,* except when a
> renegotiation take place, in which case a SSL_ERROR_WANT_READ may occur"
>
> I am trying following methods
>
> *method 1:*
>
> 1) Thread - 1 blocks in SSL_read
> 2) Thread - 2 receive indication to stop the connection from application.
> Call SSL_Shutdown() to unblock the SSL_read in thread - 1. But this is
> dangerous as calling SSL_shutdown and SSL_read from different threads on
> same context can lead to undefined behaviour.
>
> *method 2:*
>
> 1) Thread - 1 blocks in SSL_read
> 2) Thread - 2 receive indication to stop the connection from application.
> shutdown the underlying TCP socket using system command (shutdown
> (socket_id, SHUT_WR)) that cause the SSL_read to unblock.
> 3) Thread - 1 unwind and close the TCP socket (using close(socket_id)).
> thread -1 cannot call SSL_Shutdown since the TCP socket is shutdown by
> thread - 2 for write operation. As per my understanding this violates the
> TLS standard because of not sending out the close notify handshake.
>
> How to ensure to come out of blocking SSL_read and initiate SSL_shutdown
> from same thread?
>
> Thanks,
> Mahesh G S
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Hardware client certificates moving to Centos 7

[Kyle Hamilton]

openssl x509 -noout -text -in clientcertificate.pem

You may need to extract the client certificate from wireshark, but you
could also get it from openssl s_server.

Specifically, that error message is suggesting that there's a message
digest encoded into the certificate which is unknown to the trust
path.

Chances are, it's probably MD5.  MD5 was broken a long time ago, and
is no longer trustworthy.  (SHA1 is also a possibility, but it was
made unacceptable a lot more recently.)

-Kyle H


On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden  wrote:
> Sorry how can I tell ?
>
> I can run a wireshark if necessary
>
> thanks
>
>
>> On 26 Sep 2017, at 16:36, Wouter Verhelst  wrote:
>>
>> On 26-09-17 17:26, Stuart Marsden wrote:
>>> [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding 
>>> routines:ASN1_item_verify:unknown message digest algorithm
>>
>> So which message digest algorithm is the client trying to use?
>>
>> --
>> Wouter Verhelst
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL

[Kyle Hamilton]

On Fri, Sep 22, 2017 at 9:32 AM, Richard Moore  wrote:
>
> It's also worth pointing out that CAs are banned from running OCSP servers 
> over HTTPS anyway and it isn't needed since the responses are already signed 
> - http is fine.

That argument fails when you consider that some people want the
details of who they're talking to or asking about to be confidential,
not merely authentic.

I'm a believer in the idea that SNI and the Certificate messages
should happen under an ephemeral DH or ephemeral ECDH cover.  Others
fear-monger to say "maybe they shouldn't".

(Also, for completeness, the argument that "CAs are banned from
running OCSP servers over HTTPS anyway" is a straw man at best -- not
every CA is created or intends to be a member of or subject to the
mandates of the CA Security Council, formerly known as the CA/Browser
Forum.  And every attempt to encode policy into technical standards,
attempting to prohibit certain actions for whatever misguided
administrative reasons, is subject to being bypassed by people who
understand the various parts and how to glue them all together.)

To be fair, the OCSP responder certificate may or may not be
revoked... but honestly, if you're asking the OCSP responder for the
status of its own certificate you're opening yourself up to a
subordination/subversion attack anyway.  OCSP responders should have
very short-lived certificates, to minimize the temporal subordination
attack surface.

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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Kyle Hamilton]

Certificate serial numbers must be unique.  They need not be sequential or
increasing.  (Mozilla's NSS will complain and refuse to work if there are
duplicate serial numbers.)

I tend not to re-use keys, so I've found that putting 20 bytes (while
clearing the high bit) of a digest of the SubjectPublicKeyInfo as the
serial number works in that circumstance.  [if you leave the high bit set,
then DER mandates that it be encoded with a leading 0x00 byte, which makes
it 21 bytes... which can cause problems with things built for PKIX.]

-Kyle H

On Wed, Aug 16, 2017 at 6:24 AM, Tom Browder  wrote:

> Many years ago I started a CA for one group I manage for a private
> website, and now I want to update members' client certs for the stricter
> requirements for browsers.
>
> My original cert generation was entirely automated including the following:
>
> + CN for each is an e-mail address for the member
>
> + the passphrase for each member's cert is determined from a pre-generated
> list by me, it will not change
>
> I plan to tidy my automation before the issue of new certs, but I wonder
> how critical it is to ensure unique certificate serial numbers given that
> the certs are only used for us.  I'm not even sure I'll ever revoke any
> cert (they were issued to expire sometime in 2030).
>
> So, in summary, do I need to ensure cert serial numbers are unique for my
> CA?
>
> With warmest regards,
>
> -Tom
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Is there a "Golden" CA makefile?

[Kyle Hamilton]

The short answer is "no".

The long answer is, OpenSSL is not in the business of vetting trust roots.
Its business is ensuring that TLS-secured communications happen correctly
when it is used.  If you want an 'endorsed' set of roots, you can find such
from other projects (that have no relation to OpenSSL, and for which
OpenSSL can take no responsibility).

Since I'm not a member of the OpenSSL project, I can tell you that there is
a set of root certificates, vetted by Mozilla, available as part of
Mozilla's NSS (Network Security Services) project.  OpenSSL cannot take any
responsibility for that set of roots or any behavior/misbehavior of any of
the CAs represented in that set.  I had also seen a script several years
ago to convert Mozilla's format to OpenSSL format, but I have not needed to
look into it and have thus lost the URL to that script since then.

-Kyle H

On Sat, Apr 29, 2017 at 10:24 AM, John Lewis  wrote:

> I am looking for a CA makefile to use with a openvpn tutorial I am
> writing https://github.com/Oflameo/openvpn_ws. Is there one officially
> endorsed by the openssl project?
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Query regarding upgrading TLS compatibility

[Kyle Hamilton]

Every new version of TLS requires code to be written.  Sometimes it can be
implemented in a binary compatible manner, and in those situations you can
get the implementation of a new TLS version by simply replacing a DLL or
equivalent dynamic library.  However, it's much more likely that the
implementation requires non-binary-compatible changes, and your application
will need to be recompiled against the new version of the library that
supports the newest TLS version.

In other words, it is very unlikely that TLS 1.3 can be implemented in a
binary-compatible manner.  It is best if you plan to recompile your
application against the version of the library that implements TLS 1.3.

-Kyle H

On Mon, Apr 3, 2017 at 2:42 AM, Hegde, Harsha 
wrote:

> Hi,
>
> I have an query regarding TLS compatibility used in my application.
> Currently we are using TLS1.2 to connect to a third party sever. Is there
> any way to always use the highest TLS available version without modifying
> or recompiling the application code whenever there is any new version of
> TLS released.
>
>
>
>
>
> Thanks & Regards
>
> Harsha
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Cannot read exported PKCS12 cert and private key

[Kyle Hamilton]

Enhancement request:

make 'pkcs12' support -inform and -outform.

On Mon, Mar 13, 2017 at 9:26 AM, Gary L Peskin  wrote:

> Thanks VERY much Michael.  That did the trick.  This was a homegrown CA
> cert and I needed it to sign a certificate request for testing purposes.
>
>
>
> I didn’t realize that the openssl pkcs12 utility didn’t support PEM
> encoding for input.  I was a little confused I guess by the documentation
> which shows PEM encoding for “-in filename” but I see now that that’s for
> when exporting a PKCS#12 file, not for parsing one.
>
>
>
> Thanks again for clearing this up.  It’s weird that MS supports this input
> format but openssl does not. I thought openssl could do EVERYTHING.  
>
>
>
> Thanks,
>
> Gary
>
>
>
> *From:* openssl-users [mailto:openssl-users-boun...@openssl.org] *On
> Behalf Of *Michael Wojcik
> *Sent:* Monday, March 13, 2017 8:58 AM
>
> *To:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] Cannot read exported PKCS12 cert and
> private key
>
>
>
> I'll assume you mean you exported it "from a mainframe system" using RACF.
> RACF has half a dozen export formats for certificates and keys; they're not
> all supported by OpenSSL.
>
>
>
> In particular (and despite the PEM delimiters), I suspect what you have
> here is a PKCS#12 file in PEM format. The openssl pkcs12 utility doesn't
> support PEM encoding, because that's not normally done. RACF will do it,
> though, just to be difficult.
>
>
>
> openssl asn1parse -in *file* -inform pem shows you have valid ASN.1 data,
> with a big ol' blob at offset 26; adding -strparse 26 shows encrypted data.
> So yes, looks like PKCS#12.
>
>
>
> So, try this:
>
> 1. Edit the file and remove the PEM delimiters (" BEGIN CERTIFICATE
> " and "- END CERTIFICATE ").
>
> 2. Convert the data from Base64 to binary:
> openssl base64 -d -in *file* -out *file.der*
>
> 3. Unpack it:
>
> openssl pkcs12 -in *file*.der -nokeys -out *file*-cert.pem
>
> openssl pkcs12 -in *file*.der -nocerts -out *file*-key.pem
>
>
>
> Note the final openssl command will prompt you for the password to encrypt
> the key file with; if you don't want your private key encrypted, you can
> also specify -nodes.
>
>
>
> You can use openssl pkcs12 just once, without the -nokeys / -nocerts
> options, but that will put your certificate and key in the same file, which
> is generally not what you want with OpenSSL.
>
>
>
> Of course, you haven't told us what you're trying to do, so I'm just
> guessing.
>
>
>
> Also, I can't verify this, because I don't have the import password for
> your PKCS#12 file.
>
>
>
>
>
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
>
>
>
>
> *From:* openssl-users [mailto:openssl-users-boun...@openssl.org
> ] *On Behalf Of *Gary L Peskin
> *Sent:* Monday, March 13, 2017 08:39
> *To:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] Cannot read exported PKCS12 cert and
> private key
>
>
>
> My original message accidently included an attachment.  Please ignore the
> attachment.  That was not related to this issue.
>
>
>
> Thanks,
>
> Gary
>
>
>
> *From:* Gary L Peskin [mailto:ga...@firstech.com ]
> *Sent:* Monday, March 13, 2017 2:28 AM
> *To:* 'openssl-users@openssl.org' 
> *Subject:* Cannot read exported PKCS12 cert and private key
>
>
>
> Hello all
>
>
>
> I exported a certificate and corresponding private key in base 64 encoded
> DER format from a mainframe system and FTP’d it to my Windows desktop.
>
>
>
> I tried to read it using OpenSSL 1.0.2.k and 1.1.0d 32-bit and 64-bit on
> Windows with
>
>
>
> openssl pkcs12  -in mycert.p12  -noout
>
>
>
> But I get the following messages:
>
>
>
> 15956:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong
> tag:.\crypto\asn1\tasn_dec.c:1199:
>
> 15956:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1
> error:.\crypto\asn1\tasn_dec.c:374:Type=PKCS12
>
>
>
> I’m able to import this with the private key into the Windows certificate
> store with no issues.
>
>
>
> Can someone please advise as to what I’m doing wrong?
>
>
>
> Thanks,
>
> Gary
>
>
>
> PS Here is the file:
>
>
>
> -BEGIN CERTIFICATE-
>
> MIIKCAIBAzCCCcQGCSqGSIb3DQEHAaCCCbUEggmxMIIJrTCCBE8GCSqGSIb3DQEH
>
> BqCCBEAwggQ8AgEAMIIENQYJKoZIhvcNAQcBMBwGCiqGSIb3DQEMAQMwDgQIjdBS
>
> +TZF+xQCAgP5gIIECNtJIUg23ab7AXi33MKueO03S1pUkHCQk+kByNK/6f1FgEvu
>
> XRqhniR3mdyzeMVBCrCBSx3GhZlpLcW/d6OAd3z8hbXjvw5OC5OLavemfRNtsi+R
>
> q9LggkcWT2oCszc2nglKzHYaFnkG80vwxLwUXmROL+UK4ZlYmqp46EjuNAEo/yqQ
>
> yEwgia3iP84wiZRfY9kBJMq9yUm+LvowO/1E9v/ycgE6IWe1CrThQzrD6Vm9LaTy
>
> 0oZqAbTbzbedZwGsuWZoedw2FtmRijkH5EbRNRpTrUUO/qQMO19v5IKtd4kUAWea
>
> dpYrwn1kkD2aInKKsjycCFtGopXPbmrqj2cm335cESN4XePBHQuzaywHgd0WjU5O
>
> ++UM+B/5Kpx3af53E412pGAcgnPH/ZQKMa5Zkp73pcFmViLEC7Tn9eNB2iNUfX9p
>
> rV3RNRnrEPZlD1MuYEkmBIWA5czUiDKrpyYA1fmrSsFthFMhD5fTVoDMSTBmNXPz
>
> 

Re: [openssl-users] General approach for keeping a client cert from openssl

[Kyle Hamilton]

You cannot keep the certificate from OpenSSL, as that's the piece that you
share with the remote side.  This contains the public key, and the
information bound to that public key by the CA.

However, you can keep the private key from being seen by OpenSSL.  There
exists what is called an ENGINE interface to offload cryptographic
operations to a container.  Right now,
https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_indigenous_ECDH_ECDSA_and_HASH_Algorithms
seems to be the best documentation available to explain the process of
creating it.  Obviously, depending on the type of key you're using, you
will probably need to figure out the differences.

-Kyle H

On Mon, Dec 19, 2016 at 3:22 AM, Andy Green  wrote:

> Hi -
>
> I have a situation coming up that is similar to a client cert being
> held on a secure key store, like a key vault.
>
> We need to be able to perform TLS communication with a remote server
> using the key, but without giving the key to OpenSSL.
>
> The "other side" of the "key vault" is smart, and we can run code
> there, and communicate with it.  So we need to basically proxy OpenSSL
> operations on the "other side".
>
> I guess this is nothing new under the sun... what's the general
> approach to integrating this to OpenSSL?
>
> Thanks for any advice.
>
> -Andy
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] TLS Heartbeat

[Kyle Hamilton]

disable O_NAGLE on the socket?

-Kyle H

On Sat, Dec 10, 2016 at 8:04 AM, Salz, Rich  wrote:

> Heartbeats?  Yuk, why.
>
>
>
> Most likely, TCP is buffering things until you get a big enough data
> packet.   I don’t know how to address that.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] ECC patent status questions

[Kyle Hamilton]

On Thu, Sep 1, 2016 at 3:43 PM, Salz, Rich  wrote:

> > The existence of the NSA agreement is a partial answer to the first
> question,
> > though it seems unclear if this license is recursively sublicensed
> through 3rd
> > parties or not.
>
> They knew they were licensing an open source toolkit.
>

So, it looks as though the only way for any one of us to be able to have a
patent license under the NSA's license to OpenSSL Software Foundation is to
get a separate license from you that doesn't allow us to redistribute or
resell it.  (I'm not a lawyer, but it appears to be the only way that we
would be able to qualify under the "End User" definition 1A, as referenced
in the grant under section 2.)

Is such a license available?  Could such a license be granted severally to
the same people who also receive the standard BSD license, such that each
individual actually receives two separate licenses for the same code (i.e.,
one granted with extremely limited rights solely for the purpose of
qualifying to receive the NSA ECC patent license, the other being
separately granted to permit redistribution and resale of integrated
components but not granting any ECC license transitively)?

If such a severed license were possible, I would think that such would
require that the recipient of the first (limited) license obtain the code
directly from openssl.org.

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

Re: [openssl-users] Openssl and floating point

[Kyle Hamilton]

This is compiler-dependent, and because you didn't specify what platform
you're targeting or what compiler you're using, there's no way for us to
provide an answer.  Check your compiler's documentation.  GCC, for example,
provides software-emulated floating point for platforms without hardware
support.  Many other open-source and commercial compilers do as well.

-Kyle H


On Wed, Aug 10, 2016 at 6:26 AM, Kenneth Goldman 
wrote:

> We have a platform that does not support floating point operations.  We
> discovered that openssl uses floating point in the random number generator.
>
> Is there any build or compile time flag that uses an alternative to
> floating point?
>
> --
> Ken Goldman   kgold...@us.ibm.com
> 914-945-2415 (862-2415)
>
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Validation status of openssl-fips-2.0.11?

[Kyle Hamilton]

On 2/12/2016 2:03 PM, Steve Marquess wrote:
> On 02/12/2016 04:26 PM, Kyle Hamilton wrote:
>> I'm not seeing anything about openssl-fips-2.0.11 in
>> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747
>> , so I'm not quite certain what its validation/certificate status is? 
> Ok, this is complex, insanely so.
>
> [concise explanation of insanely complex and incredibly messy situation 
> trimmed]
>
> Yeah, it's a mess.

Thank you for explaining it.  It feels to me like they're intentionally
making it as difficult as possible for OpenSSL to maintain its validations.

#2398 has the correct version that I'm looking for, so that's what I'm
documenting.  However, it also suggests that there's a 2.0.12 that was
validated as of 02/08/2016?  This is not yet distributed on the website.

>> Also, is a new Security Policy in the works integrating the new HMAC
>> digests for the new versions of -fips and -fips-ecp?
> I don't understand this question.

https://openssl.org/docs/fips/SecurityPolicy-2.0.pdf points to
SecurityPolicy-2.0.9.pdf; this is the version that I got, which did not
have the new HMAC values for openssl-fips-ecp-2.0.11.tar.gz.  I was
wondering if there was a SecurityPolicy-2.0.11.pdf.  It appears there
is, but the "official" link to 140sp2398.pdf points to a
SecurityPolicy-2.0.12.pdf.  So, I can't quite manage to figure out if
I'm getting my security policy through a secure path (please see the end
of this email for more on what I mean, and why I say this).

>> (Also, would the mandatory HMAC calculation of the original tarball be
>> okay if it were done using a FIPS-validated version of Mozilla's NSS?)
> You wouldn't believe how deep that rabbit hole goes. See section 6.6 of
> the OpenSSL FIPS user guide
> (https://openssl.org/docs/fips/UserGuide-2.0.pdf). The answer to that
> question is why we're still snail-mailing CDs (see
> http://openssl.com/fips/verify.html).

My understanding of this requirement is:  A secure path can only be
established via mail/courier, or via some series of FIPS-validated
cryptographic modules.

As a result, I cannot use any non-validated openssl to bootstrap to a
validated openssl-fips, because the chain of FIPS-validated
cryptographic verification must not be broken.  If I have another
FIPS-validated module which is validated for SHA1-HMAC, I can use it in
accordance with its security policy to perform the HMAC verification. 
If I already have a FIPS-validated openssl, I can use it.  Otherwise, I
must obtain the CD from OpenSSL Foundation (most likely via registered
mail -- not even certified mail, but registered mail).

There do exist other FIPS-validated modules, like the FIPS-validated
NSS: I've already set all of the cryptography in my Firefox installation
to be through the NSS FIPS module (using cipher
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS 1.2 --
compliant with the FIPS TLS implementation guidance).  Since I'm using a
FIPS-validated NSS to perform the cryptography to download from
https://openssl.org/source/openssl-fips-ecp-2.0.11.tar.gz, would that
pass the "secure path" challenge, or would I still need to write
something to perform the HMAC test specified in Appendix B of the
Security Policy using the NSS FIPS module?

I suspect the answer depends on whether openssl.org's TLS stack is using
OpenSSL in FIPS mode.  Because I do not know if it is (and the site
itself does not mention it), I think I should assume that the TLS stack
of openssl.org does NOT operate in FIPS mode, and thus I shouldn't rely
on it as being part of the necessary trusted path.  Because of this, I
think I should assume that HMAC verification in accordance with Appendix
B is still compelled.

I hope that this insight might be helpful, though.

-Kyle H

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

[openssl-users] Validation status of openssl-fips-2.0.11?

[Kyle Hamilton]

I'm not seeing anything about openssl-fips-2.0.11 in
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747
, so I'm not quite certain what its validation/certificate status is? 
Also, is a new Security Policy in the works integrating the new HMAC
digests for the new versions of -fips and -fips-ecp?

(Also, would the mandatory HMAC calculation of the original tarball be
okay if it were done using a FIPS-validated version of Mozilla's NSS?)

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

Re: [openssl-users] Configure and config in openssl source folder

[Kyle Hamilton]

My understanding is, you must follow the steps given in the Security
Guide *exactly*, with no deviation, in order to produce a validated
binary of the FIPS canister.  In other words, you *must not* try to use
Configure when attempting to build the FIPS canister because it does not
match the steps given in the Security Guide.

Once you have the FIPS canister, you can build a version of OpenSSL that
uses it pretty much indiscriminately (as long as you ensure that all the
things that fipsld does actually happen when it comes time to link).

(I apologize if my knowledge is out of date, I haven't been following
the FIPS development for a couple of years.)

-Kyle H

On 2/10/2016 12:23 PM, cloud force wrote:
> Hi Everyone,
>
> I am trying to build FIPS capable OpenSSL as an Ubuntu 12.04 package.
>
> From the OpenSSL doc it mentioned we need to do ./config fips in order
> to build openssl under tips mode. I tried that and it worked well.
>
> Now I am building the OpenSSL FIPS as a Ubuntu package. I noticed the
> package manager meta script use the Configure (instead of config
> script) under the openssl source folder.
>
> I was wondering should I also do "Configure fips", if I use the
> Configure script to configure the source tree? What's the relationship
> between config and Configure scripts?
>
> Or should I just run ./config fips first and then let the package
> manager script to run Configure?
>
> Thanks.
> Rich
>
>
>

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

Re: [openssl-users] Configure and config in openssl source folder

[Kyle Hamilton]

./config autodetects the platform and such, passing various parameters
to Configure. So, after you've built the canister, you can do as you want.

So, to do this, figure out from ./config what parameters it passes to
Configure in the presence of the 'fips' argument, then modify the
command line the packaging script invokes accordingly.

-Kyle H

On 2/10/2016 12:47 PM, cloud force wrote:
> Thanks Kyle.
>
> Yes, for building FIPS canister I did exactly the same thing as it
> mentioned in the security policy doc.
>
> My questions above were mainly regarding building the OpenSSL library
> itself with the fipscanister.o modules.
>
> In the doc it said we should just do "/*config fips*/", and since the
> Ubuntu OpenSSL packaging script does not run /*config*/ script and it
> run /*Configure*/ script instead, I was wondering should I still run
> "./config tips" before run the Configure script, or should I just run
> "Configure fips" instead?
>
> Thanks,
> Rich
>
> On Wed, Feb 10, 2016 at 12:37 PM, Kyle Hamilton <aerow...@gmail.com
> <mailto:aerow...@gmail.com>> wrote:
>
> My understanding is, you must follow the steps given in the
> Security Guide *exactly*, with no deviation, in order to produce a
> validated binary of the FIPS canister.  In other words, you *must
> not* try to use Configure when attempting to build the FIPS
> canister because it does not match the steps given in the Security
> Guide.
>
> Once you have the FIPS canister, you can build a version of
> OpenSSL that uses it pretty much indiscriminately (as long as you
> ensure that all the things that fipsld does actually happen when
> it comes time to link).
>
> (I apologize if my knowledge is out of date, I haven't been
> following the FIPS development for a couple of years.)
>
> -Kyle H
>
>
> On 2/10/2016 12:23 PM, cloud force wrote:
>> Hi Everyone,
>>
>> I am trying to build FIPS capable OpenSSL as an Ubuntu 12.04 package.
>>
>> From the OpenSSL doc it mentioned we need to do ./config fips in
>> order to build openssl under tips mode. I tried that and it
>> worked well.
>>
>> Now I am building the OpenSSL FIPS as a Ubuntu package. I noticed
>> the package manager meta script use the Configure (instead of
>> config script) under the openssl source folder.
>>
>> I was wondering should I also do "Configure fips", if I use the
>> Configure script to configure the source tree? What's the
>> relationship between config and Configure scripts?
>>
>> Or should I just run ./config fips first and then let the package
>> manager script to run Configure?
>>
>> Thanks.
>> Rich
>>
>>
>>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
>

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

Re: [openssl-users] Configure and config in openssl source folder

[Kyle Hamilton]

The FIPS module will explicitly deny any attempt to use unapproved
algorithms when it's in FIPS mode.  It's only when it's not in FIPS mode
that you might be able to use the unapproved algorithms, because the
generated library will use the original code and not the FIPS canister.

So, if you want to disable the use of rc4 even when it's not in FIPS
mode, pass no-rc4.  FIPS mode will disable it as a matter of course.

-Kyle H

On 2/10/2016 1:08 PM, cloud force wrote:
> Thanks Kyle. So basically I can just use Configure for building FIPS
> capable OpenSSL library, as long as I pass the right parameters to it
> right?
>
> Also if I use Configure, do I need to explicitly turn off the non-FIPS
> approved algorithms, like passing "no-rc4" as a parameter to the
> Configure command?
>
> I understand it's not necessary do that if I use config script.
>
> Thanks,
> Rich
>
>
> On Wed, Feb 10, 2016 at 12:57 PM, Kyle Hamilton <aerow...@gmail.com
> <mailto:aerow...@gmail.com>> wrote:
>
> ./config autodetects the platform and such, passing various
> parameters to Configure. So, after you've built the canister, you
> can do as you want.
>
> So, to do this, figure out from ./config what parameters it passes
> to Configure in the presence of the 'fips' argument, then modify
> the command line the packaging script invokes accordingly.
>
> -Kyle H
>
>
> On 2/10/2016 12:47 PM, cloud force wrote:
>> Thanks Kyle.
>>
>> Yes, for building FIPS canister I did exactly the same thing as
>> it mentioned in the security policy doc.
>>
>> My questions above were mainly regarding building the OpenSSL
>> library itself with the fipscanister.o modules.
>>
>> In the doc it said we should just do "/*config fips*/", and since
>> the Ubuntu OpenSSL packaging script does not run /*config*/
>> script and it run /*Configure*/ script instead, I was wondering
>> should I still run "./config tips" before run the Configure
>> script, or should I just run "Configure fips" instead?
>>
>> Thanks,
>> Rich
>>
>> On Wed, Feb 10, 2016 at 12:37 PM, Kyle Hamilton
>> <aerow...@gmail.com <mailto:aerow...@gmail.com>> wrote:
>>
>> My understanding is, you must follow the steps given in the
>> Security Guide *exactly*, with no deviation, in order to
>> produce a validated binary of the FIPS canister.  In other
>> words, you *must not* try to use Configure when attempting to
>> build the FIPS canister because it does not match the steps
>> given in the Security Guide.
>>
>> Once you have the FIPS canister, you can build a version of
>> OpenSSL that uses it pretty much indiscriminately (as long as
>> you ensure that all the things that fipsld does actually
>> happen when it comes time to link).
>>
>> (I apologize if my knowledge is out of date, I haven't been
>> following the FIPS development for a couple of years.)
>>
>> -Kyle H
>>
>>
>> On 2/10/2016 12:23 PM, cloud force wrote:
>>> Hi Everyone,
>>>
>>> I am trying to build FIPS capable OpenSSL as an Ubuntu 12.04
>>> package.
>>>
>>> From the OpenSSL doc it mentioned we need to do ./config
>>> fips in order to build openssl under tips mode. I tried that
>>> and it worked well.
>>>
>>> Now I am building the OpenSSL FIPS as a Ubuntu package. I
>>> noticed the package manager meta script use the Configure
>>> (instead of config script) under the openssl source folder.
>>>
>>> I was wondering should I also do "Configure fips", if I use
>>> the Configure script to configure the source tree? What's
>>> the relationship between config and Configure scripts?
>>>
>>> Or should I just run ./config fips first and then let the
>>> package manager script to run Configure?
>>>
>>> Thanks.
>>> Rich
>>>
>>>
>>>
>>
>>
>> --
>> openssl-users mailing list
>> To unsubscribe:
>> https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>>
>>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
>

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

Re: [openssl-users] Configure and config in openssl source folder

[Kyle Hamilton]

On 2/10/2016 12:47 PM, Steve Marquess wrote:
> Since you're required to start with the official tarball, and aren't
> allowed to change the contents of the tarball, not even a teeny tiny
> little bit, there is no point in dumping the tarball contents into
> your local source code management/version control system. My
> recommendation is that one time only you conduct a solemn candlelit
> ceremony in which the build is manually performed in profound and
> reverential observance of the mandated procedure. Then take the
> resulting fipscanister.* and fips_premain.* files and version control
> those from then on out. Don't try to continually rebuild the FIPS
> module from source that cannot be modified anyway. -Steve M. 

And once you build them, make sure to get SHA-256 and SHA-512 digests of
them, print them out on a piece of paper along with an "I,
__, do certify that I built the OpenSSL FIPS version
___ distribution in accordance with its Security Policy under FIPS
Certificate #_ and generated these files with the following digests,
on ." statement.  Then sign the statement.  Everything
related to FIPS is related to being able to document it, if you want to
sell to a government agency... and if you don't want to sell to a
government agency, there's no real reason for you to bother with it.

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

Re: [openssl-users] FIPS Object Module v2.0 and openssl security patches

[Kyle Hamilton]

On 2/9/2016 12:29 PM, Steve Marquess wrote:
> On 02/09/2016 03:19 PM, cloud force wrote:
>> Hello everyone,
>>
>> Would the FIPS Object Module v2.0 supposed to only work with the vanilla
>> openssl library? If I apply the security patches to the openssl library,
>> should the FIPS Object Module v2.0 still work without problems?
> You should patch OpenSSL whether you use it with the FIPS module or not.
>
> From the perspective of the FIPS 140-2 validation, stock OpenSSL is just
> application code and is out of scope. So you can patch/hack OpenSSL
> proper as much as you want; as long as the intact FIPS module is built
> per the mandated process its FIPS-ness is unaffected by OpenSSL.
>
> -Steve M.
>

...with the caveat that you cannot patch the stock OpenSSL in such a way
that any crypto operations are done by anything other than the FIPS
module, if you want to maintain the FIPS-ness of the systems you build
using it.  Formatting and processing of (including memory management
for) data that is encrypted or decrypted by the FIPS module is fair
game, which includes pretty much all of the security holes that have
happened to date in the OpenSSL library.

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

Re: [openssl-users] Segfault in libcrypto.so

[Kyle Hamilton]

I think you would probably do better to contact support for wanguard
than for openssl.  Possible issues could involve ABI incompatibility or
library selection incompatibility; since there's no way for us to know
how wanguard is structured (we can't track every product that uses
openssl), they're more familiar with its error modes and how to work
through them.

-Kyle H

On 12/17/2015 10:00 PM, Alex william wrote:
> Hello,
>
> I have been trying to install a product named wanguard and each time
> am starting a collector I receive this error message:
> segfault at efe000 ip 7ffb571e479c sp 7ffced00dcf0 error 4 in
> libcrypto.so.1.0.0[7ffb57166000+1cb000]
> And the collector stops immediately.
>
> Has anyone encountered this error or can someone help please?
>
> Thanks.
>
> Regards,
> Alex
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: Query regarding SSLv23 methods

[Kyle Hamilton]

SSL_OP_* are bitmasks.

SSL_CTX_set_options(conn-ssl_ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3);

-Kyle H

On 11/14/2014 12:37 AM, Vaghasiya, Nimesh wrote:

 Hi,

 Thanks for the info.

  

 (a typo in previous mail).

 Could you please confirm whether following will ensure my SSLv23
 methods will no more accept SSLv3 and SSLv2 connections ?


 conn-ssl_ctx = SSL_CTX_new(SSLv23_server_method());


 SSL_CTX_set_options(conn-ssl_ctx, SSL_OP_NO_SSLv2);
 SSL_CTX_set_options(conn-ssl_ctx, SSL_OP_NO_SSLv3);


 Regards,
 Nimesh
 
 *From:* owner-openssl-...@openssl.org [owner-openssl-...@openssl.org]
 on behalf of Viktor Dukhovni [openssl-us...@dukhovni.org]
 *Sent:* Friday, November 14, 2014 12:05 PM
 *To:* openssl-users@openssl.org
 *Subject:* Re: Query regarding SSLv23 methods

 On Fri, Nov 14, 2014 at 06:26:24AM +, Vaghasiya, Nimesh wrote:

 [ It is rude to ask user questions on the dev list (moved to Bcc). ]

  We are in process of disabling SSLv3 and SSLv2 protocols from all of
 our FreeBSD based applications.
 
  For SSLv23 methods we are setting SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3
 options as shown below,
 
 
   conn-ssl_ctx = SSL_CTX_new(SSLv23_server_method());
   SSL_CTX_set_mode(conn-ssl_ctx, SSL_OP_NO_SSLv2);
 
   SSL_CTX_set_mode(conn-ssl_ctx, SSL_OP_NO_SSLv3);
 
  Does this ensure my SSLv23 methods will no more accept SSLv3 and
 SSLv2 connections ?

 No, it does not.

 You really should read the manpage for SSL_CTX_set_mode(3) that
 function is unrelated to setting the options in question.

 To control protocol feature and work-around options see
 SSL_CTX_set_options(3).

 -- 
 Viktor.
 __
 OpenSSL Project http://www.openssl.org
 http://www.openssl.org
 Development Mailing List   openssl-...@openssl.org
 Automated List Manager   majord...@openssl.org



smime.p7s
Description: S/MIME Cryptographic Signature

Can SSL_v23_method be renamed or have additional name assigned?

[Kyle Hamilton]

There's a fair amount of grumbling that I see on Twitter about how
SSLv23_method is confusing -- what it does is the autonegotiation
capability.

So, could it perhaps get a new name (or alias) of something like
SSLnegotiate_method? 

What would be the pros and cons of such an aliasing?

-Kyle h



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Generating the corresponding public key of a private key

[Kyle Hamilton]

OpenSSL doesn't really have a lot to do with ssh-keygen (though
ssh-keygen might link against libcrypto, SSH is not SSL).  You should
probably send to the OpenSSH mailing lists to get help there.

-Kyle H

On 10/12/2014 11:38 PM, Angelos Ching wrote:
 Hi,

 Can I always expect the following commands, when given the same
 private key, to generate the same public key albeit in different format?
 # ssh-keygen -y -f id_rsa
 # ssh-keygen -e -f id_rsa

 Because I'm dealing with one private key that is generating different
 public key when the above commands were executed.
 The output between the 2 commands are different, but they are
 consistent for any number of runs.
 Moreover, if I copy id_rsa to, say, id_rsa.priv:
 # ssh-keygen -y -f id_rsa.priv
 # ssh-keygen -e -f id_rsa.priv
 would generate the same public key output.

 Running OpenSSL 1.0.0-fips 29 Mar 2010

 Best regards,
 Angelos
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org




smime.p7s
Description: S/MIME Cryptographic Signature

Re: best practice for creating a CA cert?

[Kyle Hamilton]

Generally, a client doesn't bother checking a certificate that's in its local 
trust store. The idea is, if it's in its trusted store, there's no need to 
verify its integrity, because the administrator already performed that 
verification.

Where this might have an impact is if your new certificate is cross-certified 
by another organization's root. You'll have to judge for yourself how likely 
this scenario might be for your environment.

-Kyle H

On September 28, 2014 11:59:29 PM PDT, Jason Haar jason_h...@trimble.com 
wrote:
Hi there

Due to the upcoming Google instigated phasing out of SHA-1, I'm looking
at creating a new enterprise CA (ie internal only)

If I just click through the defaults of openssl ca, I'd probably
end
up with a 2048bit RSA, SHA-2 (256) cert. So my question is, should I
future proof that by making it 4096bit and maybe SHA-2 (512)? (ie I
want
the CA to be viable for 10 years, not 5 years). What is the performance
impact of increasing these values of the CA cert itself? I'd expect to
still only sign 2048-bit, SHA-256 server/client certs - but is there a
real performance downside to making the CA cert itself stronger? I
don't
care if the CA takes 30 seconds longer to sign a cert - but I'd really
care if it made a web browser hang when talking to the resultant server
cert ;-)

Thanks!

-- 
Cheers

Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Problem with Certificate Chains on Windows

[Kyle Hamilton]

Check the digests used for signing. Windows (after updates) may refuse MD5 
signatures on certificates; I would recommend regenerating new certs with at 
least SHA256.

-Kyle H


On September 22, 2014 9:34:59 AM PST, Vellore-Arumugam, Jagdish (Svr 
Automation) jagdish.arumu...@hp.com wrote:
Hi,

I am getting a 'Certificate Signature Failure' (verify
error:num=7:certificate signature failure) on Windows Server 2008 R2
Enterprise during certificate verification on the client side. I used
the 'openssl s_client' command to check this behavior after seeing SSL
handshake failure in my application that uses Python M2Crypto for the
SSL communication. This failure is seen only on the windows platform,
RHEL and Ubuntu running the same python app using the same certificates
does have this problem. The CAs are loaded from files that contain:

Cert #1: Single self-signed cert with Subject ='ABC' and Issuer = 'ABC'

And the following chain of 3 certs

Cert#2: This is part of a cert chain with Subject = 'ABC' and Issuer =
'ABC'
Cert#3: Intermediate CA Subject = 'ABC' and Issuer = 'Custom CA'
Cert#4: Self-signed root Subject = 'Custom CA' and Issuer = 'Custom CA'

Cert #1 and the chain have overlapping validity dates, so both are
currently valid.

I encounter the problem only when I load 2 such CA files. One that
corresponds to the server cert ('ABC') and another (say 'XYZ') that is
used to verify a different server cert. The structure of both the certs
are identical and the chains in them use the same self-signed root
cert. But each have different Subject and Issuer for the top level cert
('ABC' and 'XYZ).

I used exactly the same certificates for my Unix clients and they do
not have this problem. An identical 'openssl s_client' command is
successful on the Unix clients.

I am using OpenSSL 1.0.1h libraries.

Any suggestions on how to troubleshoot/resolve this problem will be
very helpful.

Thank you,
Jag.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: TLS handshake failure i/o timeout

[Kyle Hamilton]

This may sound basic, but have you verified that the firewall on the server is 
set up to allow communication from the client? I think Ubuntu's firewall 
rejects all traffic to ports that don't match what its installed and configured 
packages claim they run on, without external configuration.

-Kyle H

On September 18, 2014 6:02:16 AM PDT, espe...@oreillyauto.com wrote:

I have an ubuntu 14.04 with openssl 1.0.1f-1ubuntu2.3 server running
and a
another server connecting as the client with ubuntu 12.04 with openssl
1.0.1-4ubuntu5.16.  I am getting an error about the TLS handshake
failing
i/o timeout.  I have tried using our internal wildcard certs on both
servers since I already have that on my web server , aka - the client,
and
I generated a sif signed cert on the server and copied it to the
client.
Both produce the same results.

On the server I took a tcpdump and then did an ssldup of that file and
this
is what I am seeing for every connection:

210 1 0.0012 (0.0012) CS Handshake
ClientHello
Version 3.1
cipher suites
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
Unknown value 0xc011
Unknown value 0xc012
Unknown value 0xc013
Unknown value 0xc014
compression methods
NULL

I have looking through posts trying to find an answer with no luck yet.
Any and all help is appreciated.

Thanks,
Eric Speake
Web Systems Administrator
O'Reilly Auto Parts
 (417) 862-2674  Ext. 1975

This communication and any attachments are confidential, protected by
Communications Privacy Act 18 USCS � 2510, solely for the use of the
intended recipient, and may contain legally privileged material. If you
are not the intended recipient, please return or destroy it
immediately. Thank you.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Can we have a PyOpenSSL 0.15?

[Kyle Hamilton]

I don't think this is the right place to ask on. This list is for OpenSSL 
itself, not the python binding to it.

The PyOpenSSL folks may be watching this list, but this list is probably not 
the official list to discuss it.

-Kyle H

On September 8, 2014 8:56:35 AM PST, Eric Chazan eric.cha...@sungardas.com 
wrote:
All,

My team is considering a port to Python 3 from Python 2.7.  One issue
we
see is that we cant run a flask server with ssl.  I am seeing that the
fix
is in this pull request:

https://github.com/pyca/pyopenssl/pull/78/commits


Which has already been merged.  Is a new version of PyOpenSSL coming
that
contains this pull request?

Thanks,
Eric Chazan

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

RE: Certificate pass phrase brute force...

[Kyle Hamilton]

At least 3DES is *some* encryption. The issue is that peoples' computers are 
usually infested with malware; it's better to assume (for a software 
distribution) that the disk is compromised, and always encrypt it before 
writing.

Perhaps there should be a cipher option for the req -newkey option?

-Kyle H

On September 9, 2014 8:58:08 AM PST, Michael Wojcik 
michael.woj...@microfocus.com wrote:
As far as I know, openssl req doesn't let you specify the encryption
cipher for the private key.

You can generate the key file first, with openssl genpkey, which does
let you specify the encryption cipher; and then use -key to tell
openssl to use your existing key rather than creating a new one.

You can also do what you describe below, but not encrypt the private
key the first time, by using the -nodes option with openssl req; that
saves decrypting it before encrypting it with your preferred cipher.


Michael Wojcik
Technology Specialist, Micro Focus


From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop
Sent: Tuesday, 09 September, 2014 01:19
To: openssl-users@openssl.org
Subject: Re: Certificate pass phrase brute force...

I used the asn1parse command [thanks Dave!] and while the key looks
old style it parses as follows:

50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc

Which appears to equate to: des-ede3-cbc   Three key triple DES EDE
in CBC mode

The full asn parse is:
---
 0:d=0  hl=4 l=2446 cons: SEQUENCE
   4:d=1  hl=2 l=  64 cons: SEQUENCE
   6:d=2  hl=2 l=   9 prim: OBJECT:PBES2
  17:d=2  hl=2 l=  51 cons: SEQUENCE
  19:d=3  hl=2 l=  27 cons: SEQUENCE
  21:d=4  hl=2 l=   9 prim: OBJECT:PBKDF2
  32:d=4  hl=2 l=  14 cons: SEQUENCE
34:d=5  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:ABCABCABCABCABCA
(REDACTED)
  44:d=5  hl=2 l=   2 prim: INTEGER   :0800
  48:d=3  hl=2 l=  20 cons: SEQUENCE
  50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc
60:d=4  hl=2 l=   8 prim: OCTET STRING  [HEX DUMP]:ABCABCABCABCABCA
(REDACTED)
---
[I don't know if I needed to redact those fields at all, but I don't
think it matters.)

So, if I've read that properly, the encryption method is 3DES.

---
While this isn't really relevant to OpenSSL, and more relevant to the
EasyRSA script from OpenVPN - I thought I'd share a solution that
appears to work and do what I want.

It doesn't appear easy to modify the EasyRSA script to use aes-256 [or
any non 3DES cypher] in the script. From my look at the syntax of a
openssl req -new -newkey ... command, you don't get to specify the
cypher it will use in encrypting the private key. This appears to be a
result of generating both the key and the signing request in a single
step - in this case you don't appear to get to choose what crypto is
used to encrypt the private key. [I'd be glad to be shown a way you can
specify it - it doesn't appear possible from the command-line options
at least.]

However, as I pointed out there is code in the EasyRSA tool to
re-encrypt the private key with a new password, or remove the password.
You can edit the script to use aes256 as follows: [or any of the other
cyphers here:
https://www.openssl.org/docs/apps/rsa.html#https://www.openssl.org/docs/apps/rsa.html]
In the easyrsa bash script:
Look for the line: [ local crypto=-des3 ] (It's line 861 in the
current EasyRSA version)
Change it to: [ local crypto=-aes256 ]

Now when you issue the command easyrsa set-rsa-pass, and issue the
old encryption key, along with a new one [you can certainly use the
same key for the old and new] it will re-encrypt it with aes-256.

Looking at the key file it does appear to indeed work and re-encrypts
it with AES-256.

#cat somekey.key
-BEGIN RSA PRIVATE KEY-
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC ...

---
Thus, this is the best work-around for the tool I can find.
Unfortunately it requires a redundant step unless someone can show me
a way to put the encryption type for private keys in a config file or
specify it as part of a openssl -req ... command

But at least it works the way I want it to, and makes the task of
setting up keys and certs a bit easier than raw openssl commands.

Hope that helps someone else too. And thanks again for all the pointers
and tips!

[Ya'll are probably going to chuckle and say If you'd just dumped that
lousy 'playskool' EasyRSA tool and run openssl like a real man, you'd
have avoided all this hoopla in the first place! And yeah, you're
probably right - but I trust a good script to do it right more often
than I trust myself - but perhaps that trust is misplaced in this
case.]

Again, glad for any follow-up advice - it's been an interesting thread
- at least for me.

-Greg


For the legacy formats (dashes-BEGIN PRIVATE RSA KEY or PRIVATE EC KEY)
just look on the DEK-Info: header line.

For PKCS#8 format (dashes-BEGIN ENCRYPTED PRIVATE KEY) do
 openssl asn1parse key.pem
and the third line will be an OBJECT (really OID) in the 

Re: Verifying authenticode signature using openssl API

[Kyle Hamilton]

http://msdn.microsoft.com/en-us/windows/hardware/gg463180.aspx is the spec for 
the Authenticode PE signature format.

http://msdn.microsoft.com/en-us/gg463119 is the Microsoft PE and COFF 
Specification.

Better download them now before they disappear, they appear to be deprecated in 
favor of Windows 8 format packages (of which I have no information).

On September 9, 2014 10:18:18 AM PST, Prasad Dabak pda...@icloud.com wrote:
Thanks Jacob for your response. Very informative indeed!

Thanks
-Prasad

Sent from my iPhone

 On 09-Sep-2014, at 10:05 pm, Jakob Bohm jb-open...@wisemo.com
wrote:
 
 On 09/09/2014 09:01, Prasad Dabak wrote:
 Thanks Jacob for an elaborate answer. Somehow I never received your
response to my registered email address, hence delay in responding.
 This time I have CC-ed you in addition to the mail list.
 I have a few follow-up questions on your response.
 
 1. So, encryptedDigest  has no relation to the stored
messageDigest? I thought it's a encrypted version of the
messageDigest?
 As far as I recall, there is a chain of 4 digests.  The first digest
 is calculated over the file and is stored in the spcIndirectData. The
 second digest is calculated over the spcIndirectData (the contentInfo
 of the the PKCS#7 structure) and is stored as messageDigest in the
 AuthenticatedAttributes of each PKCS#7 signerInfo.  The third hash
 is calculated over the AuthenticatedAttributes and is signed to
 produce the encryptedDigest in that same signerInfo.  All 3 need to
 be checked to confirm that the file hash is actually (indirectly)
 signed by the encryptedDigest using the public key in the certificate
 whose name is listed in the signerInfo.
 2. I agree that it's better to do cheaper checks first e.g. I am
also matching PE checksum stored in the optional header.
 Indeed, though that is a very weak checksum (file size plus 16 bit
TCP/IP
 checksum of file).  Also it is allowed to be 0 to indicate no
checksum
 (even if you set the checksum, it might be cleared if an
Administrator
 adds his own countersignature to all authorized programs on his
 computers, aka AppLocker).
 3. spcPEImageData is probably relevant only for signing that uses
page hashes?
 I never quite figured out where they store the page hashes. However I
 believe the constant semi-empty spcPEImageData with the
obsolete
 string is the traditional marker to indicate that the signature is
for
 a PE file, and not e.g. a document file with the same hashed
bytestream.
 
 4. PKCS7_verify is already matching the encryptedDigest, do we still
need to validate it ourselves?
 If it is, I am myself guessing a bit as to what that function does
and
 does not check.  But note that it probably doesn't check the full
chain
 of 3 message digests, since at least the digest over the file itself
is
 inside a blob that the PKCS#7 standard has no opinion about.
 5. So, basically are are suggesting to look into the subject string
and see if we can find patterns like /CN=COMPANY-NAME... issuer:
/C=US/O=SIGNER_NAME? How authoritative it is? I mean can someone
else have same COMPANY-NAME and PATTERN-NAME in their certificate?
 Actually, the subject is a data structure (a hierarchical list of
sets
 of tagged strings) and the relevant comparison would be to compare
those
 elements that don't change when getting a new certificate from the
CA.
 It is the CAs responsibility to make sure the don't issue
certificates
 to the wrong people, and if they make a mistake they are expected to
 quickly add the bad certificate to their published CRL, which is why
 you need to check the CRL before trusting the certificate.  An
 additional check is to make sure the CA that issued the intermediary
 certificate that issued the COMAPNY-NAME certificate is actually
one
 of the (few) CAs that COMPANY-NAME is going to buy certificates
from.
  This protects against fake certificates issued by smaller CAs that
 you aren't going to use anyway.
 
 In my case, I am the one who is signing the executable using my
certificate and a cross certificate issued by Microsoft and I want to
programmatically ensure following things.
 
 1. Code is not tampered since it was signed (matching messageDigest
with computed hash)
 Actually matching digest in spcIndirectData with computed hash. Plus
 consistency checks to make sure the signature is actually for a PE
file
 and was not otherwise doctored.  For instance there should be no
bytes
 in the file after the end of the signature blob.
 2. Verifying the digital signature (PKCS7_Verify)
 3. Confirming that the executable is signed by my company
certificate.
 
 I am stuck on part (3) and don't see a clean way apart from matching
strings in subject field?  If I hard-code the public key in my
verification code, I will need to update it when I switch to a newer
public key?
 Yep, that is why careful matching against various Distinguished Name
 fields is needed.
 
 
 On Sep 06, 2014, at 09:44 PM, Prasad Dabak pda...@icloud.com
wrote:
 
 Hello,
 
 Given a 

Re: Certificate pass phrase brute force...

[Kyle Hamilton]

Having a sterile VM to do all of the cert generation is a good idea. But can 
you guarantee, in these days of logging and versioned filesystems, that the 
unencrypted key file data block will in fact be overwritten by the encryption? 
Or will it remain intact, with a new data block allocated for the new content?

(Also, I'm trying to generalize good security principles to the design of a 
non-specific script. I now see that you have a particular scenario with a 
particular threat model in mind, and disclaim the creation of a solution for 
general utility.)

-Kyle H

On September 9, 2014 3:27:27 PM PST, Gregory Sloop gr...@sloop.net wrote:
@Kyle: I'm the admin for the OpenVPN system setup and config, and
generate all the server/client certs, CA etc., and if my machine is
infested with malware, then well, the CA's compromised, along with
everything else. IOW, game over.

It's not that I disagree with you particularly, but I doubt that the
short time a private key is exposed before it gets re-encrypted, will
matter much, especially in the very controlled situation I'm
contemplating. [Which is actually inside a sterile VM.]

---
@Michael: Yeah, I can use the EasyRSA tool to initially create the
Key+CSR without a password [encryption-less] and then add the aes-256
re-key in the second process. [Like so: # easyrsa build-client-full
somefilename nopass ] As I was writing up the post last night, I
thought about describing that process, but thought it would confuse
things further since I hadn't opened the thread that way...

But yet, that will make it easier as I only have to input the password
once into the terminal, instead of on both passes.

And you're right in regards to modifying the EasyRSA script; it's more
work than I'm able to do at the moment, and while I'm not terrible at
bash, I'd be hesitant in making fairly major mods to [security
critical] code in fear of introducing ill effects that won't get caught
in a cursory peer-review.

The current code can be made to work without too much hassle and has
been around for a while and has been real-world tested. Unless the
current maintainer is willing to do it, it's probably better to leave
it the way it is now with the minor change I suggest.

Again thanks all for the excellent help, ideas and suggestions. It's
been a pleasure. 
[And that's an uncommon compliment - far more than can be said of many
listservs.]

-Greg


Sure, if that's a better fit to your threat model. (I certainly
wouldn't recommend changing openssl req to make -nodes the default.)
I was just suggesting possibilities for Gregory.
 
Personally, I'd probably go with generating an encrypted private key
with openssl genpkey first, but that might be more changes to the
EasyRSA script than he's inclined to make. He has a working solution
now which seems fine for his purposes.
 
A cipher option for openssl req -newkey wouldn't be a bad idea, but
it's not a high priority, so I wouldn't expect it to happen anytime
soon unless someone wants to submit a patch.
 
Michael Wojcik 
Technology Specialist, Micro Focus
 
 
From: Kyle Hamilton [mailto:aerow...@gmail.com] 
Sent: Tuesday, 09 September, 2014 13:43
To: openssl-users@openssl.org; Michael Wojcik
Subject: RE: Certificate pass phrase brute force...
 
At least 3DES is *some* encryption. The issue is that peoples'
computers are usually infested with malware; it's better to assume (for
a software distribution) that the disk is compromised, and always
encrypt it before writing.

Perhaps there should be a cipher option for the req -newkey option?

-Kyle H
On September 9, 2014 8:58:08 AM PST, Michael Wojcik
michael.woj...@microfocus.com wrote:
As far as I know, openssl req doesn't let you specify the encryption
cipher for the private key.
 
You can generate the key file first, with openssl genpkey, which does
let you specify the encryption cipher; and then use -key to tell
openssl to use your existing key rather than creating a new one.
 
You can also do what you describe below, but not encrypt the private
key the first time, by using the -nodes option with openssl req; that
saves decrypting it before encrypting it with your preferred cipher.
 
 
Michael Wojcik 
Technology Specialist, Micro Focus
 
 
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop
Sent: Tuesday, 09 September, 2014 01:19
To: openssl-users@openssl.org
Subject: Re: Certificate pass phrase brute force...
 
I used the asn1parse command [thanks Dave!] and while the key looks
old style it parses as follows:

50:d=4  hl=2 l=   8 prim: OBJECT:des-ede3-cbc

Which appears to equate to: des-ede3-cbc   Three key triple DES EDE
in CBC mode

The full asn parse is:
---
 0:d=0  hl=4 l=2446 cons: SEQUENCE
   4:d=1  hl=2 l=  64 cons: SEQUENCE
   6:d=2  hl=2 l=   9 prim: OBJECT:PBES2
  17:d=2  hl=2 l=  51 cons: SEQUENCE
  19:d=3  hl=2 l=  27 cons: SEQUENCE
  21:d=4  hl=2 l=   9 prim: OBJECT:PBKDF2
  32:d=4  hl=2 l

Re: Why does OpenSSL own all the prefixes in the world?

[Kyle Hamilton]

If all you want is C++ namespaces,could you you wrap the #include lines for 
OpenSSL in a namespace declaration?  (I am not a C++ guy, I honestly don't know 
where problems would exist... except the namespaces don't do anything for 
#define, I think?)

namespace openssl {
#include ssl/whatever.h
};

Another alternative might be to not mix code that relies on defined symbols 
from one library in the same source file as one which requires a different 
library with conflicting definitions.  This would require passing context 
structs to functions in different source files, with those functions doing what 
needed to happen at that moment using the facilities available to that source 
file.

A bigger problem is that it would necessarily change the ABI to dictate that 
the symbols in the linked library cannot be linked as extern C.

Perhaps a compatibility library that forwards old-API calls to a namespaced 
library could work... but the problem there is that there are platforms still 
in use that likely have only limited C++ support.  (Such as Amiga and OS/2.)

It's not an easy problem to address, and every option has compromises.

-Kyle H

On September 7, 2014 9:44:44 PM PST, Pierre DELAAGE delaage.pie...@free.fr 
wrote:
At a time or another,
of course there would be some (hopefully limited) rewrite in apps :

not necessarily complicated: I was thinking about C++ namespaces.

It is also possible to offer to apps maintainers a global grep and 
replace script, based on ed or vi in an automated way,
to replace every BIO_xxx by, eg, OSSL_BIO_xxx in all files in some
location.
Not so difficult either.

From year to year, It would be strange that openssl is maintaining, by 
huge effort, various versions of the library (I mean for any given 
platform, whatever it is),
just to avoid that old apps be maintained themselves doing lesser 
effort.
I do not see so big problems with that, provided that, apart from 
adapting some code, people are NOT pushed to buy, to pay, to invest, to

migrate to other platform (a strategy that many OS vendors have).

If there is a switch to C++ one day, and/or a change in the API design,
there can be a kind of progressive switching period where two api's 
coexist,
one giving wrappers/redirectors to the other, or one being built on top

of the other, encapsulating it and -later- making the other NOT
public 
and then maybe completely disappearing .

It would be interesting, in that perspective, to have some statistics 
about the API functions REALLY in use in apps.
By some smart greps scripts that could be part of the openssl distrib 
(so that people avoid to reinvent the wheel and all use the same tool 
for such measurements).



Le 08/09/2014 03:52, Jakob Bohm a écrit :
 And how would you do that without breaking compatibility with every
 program (in C, C++ or any other language) that already uses openssl
and
 depends on the current API names?

 Providing the API, semantics and portability of the original SSLeay
 library is thesecond-most important feature of OpenSSL (right after
 actually being a secure SSL/TLSimplementation when used correctly).

 On 08/09/2014 01:15, Pierre DELAAGE wrote:
 Hmm...
 Switch strongly and definitely to C++
 Not for fancy object programming, but for more practical syntaxES
for 
 things like this.

 And I am an old C fan programmer...
 Pierre Delaage



 Le 08/09/2014 00:04, Kyle Hamilton a écrit :
 The reason is legacy. Eric Young was not conscious of namespace 
 pollution when he implemented SSLeay; since then, even after the 
 migration to the OpenSSL name and team, the focus has been more on 
 maintaining source compatibility than in creating new 
 interoperability opportunities.

 To meet the goal of interoperability while enabling an alternate 
 symbolic namespace, what would you suggest?

 -Kyle H

 On September 7, 2014 1:30:11 PM PST, Iñaki Baz Castillo 
 i...@aliax.net wrote:

 Hi,

 RAND_xxx
 CRYPTO_xxx
 ERR_xxx
 ENGINE_xxx
 EVP_xxx
 sk_xxx
 X509_xxx
 BIGNUM_xxx
 RSA_xxx
 BN_xxx
 ASN1_xxx
 EC_xxx

 etc etc etc.

 May I understand why it was decided that OpenSSL can own all
the
 prefixes or namespaces in the world? How is it possible that 
 OpenSSL
 owns the ERR_ prefix (for example ERR_free_strings() and
others)?

 OpenSSL is a library. I should be able to integrate OpenSSL
into my
 own code and define my own prefixes without worrying about
creating
 conflicts with the near 200 prefixes that OpenSSL owns.


 An example of a well designed C library is libuv [*], in which:

 * Public API functions and structs begin with uv_.
 * Private API functions begin with uv__.
 * Public macros begin UV_.

 That's a good design!


 PS: In my project I use both openssl and libsrtp. In which of
them
 do
 you expect the following macro is defined?:

SRTP_PROTECTION_PROFILE




 [*]https://github.com/joyent/libuv/


 Enjoy

 Jakob

Re: How to empty a BIO buffer?

[Kyle Hamilton]

The allocated buffer needs to be sizeof(char *). What's happening is the 
address of the buffer (buffer[0]) gets written to the 
pointer-to-pointer-to-char, data.  If data == NULL, you're asking to write the 
address of the buffer to unallocated memory.

It's done this way because the return value of the function is the number of 
valid bytes you can read from that location, and the address must go somewhere 
for you to get the data from it.

I'm sorry this is probably difficult to understand, I don't know if I can 
explain it more easily.

-Kyle H


On September 8, 2014 9:19:09 AM PST, Iñaki Baz Castillo i...@aliax.net 
wrote:
2014-09-08 16:08 GMT+02:00 Richard Levitte rich...@levitte.org:
 Sorry, BIO_flush() isn't what you want (it doesn't reset the buffer
to
 empty), BIO_reset() is.

 However, you need to be careful...  if I were you, I would use the
 read data before resetting, as BIO_get_mem_data() gives you the
 pointer to the internal BIO_s_mem buffer, not to a duplicate of it.


Thanks, it does work. However... I do not understand how...

This works fine:

---
long read;
// myBuffer is an already allocated buffer.
char** data = (char**)myBuffer;

read = BIO_get_mem_data(bio, data);

// Use data and read values.

BIO_reset(bio);
---

This crashes:

---
long read;
char** data = NULL;

read = BIO_get_mem_data(bio, data);

// Use data and read values.

BIO_reset(bio);
---


Why do I need to provide BIO_get_mem_data() with an already allocated
buffer? I've checked the function and I do not understand what it
does). The only I want is to get the pointer to the BIO's buffer in
which SSL_write() wrote. Why should I provide an allocated buffer? The
BIO already has a buffer and the data is already in there after
calling SSL_write(). Why do I need to pass an allocated buffer?

Thanks a lot.

-- 
Iñaki Baz Castillo
i...@aliax.net
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Why does OpenSSL own all the prefixes in the world?

[Kyle Hamilton]

The reason is legacy. Eric Young was not conscious of namespace pollution 
when he implemented SSLeay; since then, even after the migration to the OpenSSL 
name and team, the focus has been more on maintaining source compatibility than 
in creating new interoperability opportunities.

To meet the goal of interoperability while enabling an alternate symbolic 
namespace, what would you suggest?

-Kyle H

On September 7, 2014 1:30:11 PM PST, Iñaki Baz Castillo i...@aliax.net 
wrote:
Hi,

RAND_xxx
CRYPTO_xxx
ERR_xxx
ENGINE_xxx
EVP_xxx
sk_xxx
X509_xxx
BIGNUM_xxx
RSA_xxx
BN_xxx
ASN1_xxx
EC_xxx

etc etc etc.

May I understand why it was decided that OpenSSL can own all the
prefixes or namespaces in the world? How is it possible that OpenSSL
owns the ERR_ prefix (for example ERR_free_strings() and others)?

OpenSSL is a library. I should be able to integrate OpenSSL into my
own code and define my own prefixes without worrying about creating
conflicts with the near 200 prefixes that OpenSSL owns.


An example of a well designed C library is libuv [*], in which:

* Public API functions and structs begin with uv_.
* Private API functions begin with uv__.
* Public macros begin UV_.

That's a good design!


PS: In my project I use both openssl and libsrtp. In which of them do
you expect the following macro is defined?:

  SRTP_PROTECTION_PROFILE




[*] https://github.com/joyent/libuv/


-- 
Iñaki Baz Castillo
i...@aliax.net
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Certificate pass phrase brute force...

[Kyle Hamilton]

If someone has the encrypted key data, they can feed that data anywhere they 
wish. In that case, they can feed it into processing systems that do not 
enforce rate-limiting.  Thus, there is no way to do what Dave Paxton suggests 
in any case.

-Kyle H

On September 5, 2014 12:51:04 PM PST, flgirl799901 flgirl799...@gmail.com 
wrote:
I most certainly did NOT hack into anything. I thank you so much for
your response, but deplore your rudeness


Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone


 Original message 
From: dave paxton dpax...@me.com 
Date:09/05/2014  3:33 PM  (GMT-05:00) 
To: openssl-users@openssl.org 
Cc:  
Subject: Re: Certificate pass phrase brute force... 

That is easy.  Just restrict the number of different passwords per day.
Any account.  Thus the old school brute force idea passes out the
window.  Most of what you are looking at it a signing issue.  Basically
one person does a transaction and the the other person verifies it.
They do the DSA and thus they are the same person as they should be. 
That is the idea anyway.  As far as accounts go that hold those keys
then you have the few problems.  Did the client get hacked or you?  Who
can hack the account like our recent icloud picture issue.  All of this
is lazy programming.  It is really a matter of how certain you are of
the client and how you want to make sure they are who they are.  No
biggie.  Dave.


On 9/5/2014 1:03 PM, flgirl799901 wrote:
How do I unsubscribe from all of this?


Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone


 Original message 
From: Gregory Sloop gr...@sloop.net 
Date:09/05/2014 1:36 PM (GMT-05:00) 
To: openssl-users@openssl.org 
Cc: 
Subject: Certificate pass phrase brute force... 

General question: 

I've done a number of searches and can't find a lot about the subject.
[I've searched the list archives too...at least as best I could.]

In several cases, the most obvious being OpenVPN, I use client
certificates generated by openssl, with a pass-phrase [password]. This
means that if I ever have someone misplace the certificate, it can't be
used without the password. [And I have little control about what users
do with such things - they download and install software they
shouldn't; They have unknown users use their machines; They get their
machines/phones/tablets stolen etc.]

However, if someone loses control of the certificate, I need to
consider the safety of the certificate. [And I have to assume I'll
never know they lost control of it either.] Assume users are practicing
reasonable security and it's unlikely an attacker will obtain the
pass-phrase when they obtain the certificate. [A hard/bad thing
to assume, I realize.]

So, I've seen reports of Elcomsoft's tool to attempt ~6K passwords a
second against a certificate file. Let's assume two orders of magnitude
better performance for a fairly determined attacker, and we're at 600K
passwords per second. Three gets us 6M a second.

But even at 6M a sec, a non dictionary guessable pass-phrase of 10
characters will require ~380 years to break - which isn't too
bad, IMO.  [Assume a 52 character set. This obviously gets complicated
since the pass-phase probably isn't completely random etc...but
lets assume a theoretical 52 character random set.]

But since I can't find any reputable source for this kind of
data, I'm questioning the assumptions above.

Can anyone give me some pointers at a reputable attempt at quantifying
this? [The brute-force-ability and the speed at which it might be
accomplished.]
Does anyone have a policy about loss of certificates and
regeneration/revocation along with the underlying reasoning they're
willing to share?

Or, perhaps I completely misunderstand what's going on, and I'd be glad
to be corrected. [Gently is always nice.]

TIA
-Greg





-- 
Dave Paxton
dpax...@me.com
208 570 9755
skype: dpaxton

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.