Re: [openssl-users] build.info

[Wouter Verhelst]

On 9/3/18 9:05 PM, Thomás Inskip wrote:
> Does anyone know how I can specify that a specific shared library (in
> this case an engine) is dependent on a system-installed shared library
> (i.e. not built along with openssl)?.  Basically the equivalent of
> LDFLAGS += -lsomelib
The GNU runtime dynamic library will honor DT_NEEDED flags of libraries,
too. That is,  you can just do LDFLAGS += -lsomelib on a library target
and it will work. Check libgtk-3.so, for instance:

objdump -x /usr/lib/x86_64-linux-gnu/libgtk-3.so

will show a bunch of lines like...

Dynamic Section:
  NEEDED   libgdk-3.so.0
  NEEDED   libgmodule-2.0.so.0
  NEEDED   libpangocairo-1.0.so.0
  NEEDED   libX11.so.6
  NEEDED   libXi.so.6
  NEEDED   libXcomposite.so.1
  NEEDED   libXdamage.so.1
(...)

Meaning, all these libraries need to be loaded for libgtk-3.so to work.

Beware gotchas:

- Not all rtdl implementations do so, so if you're not using a GNU
platform (e.g., Linux), then check the documentation of your runtime
dynamic linker.
- This works for shared libraries, but not for static ones.

Regards,


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

Re: [openssl-users] About 1.0.2p version release !!

[Wouter Verhelst]

It does (and that's the whole point of it)


On 13-08-18 05:31, Short, Todd via openssl-users wrote:
>
> That site can’t be reached… (at least by me, unless it requires TLSv1.3…)
>
>  
>
> --
>
> -Todd Short
>
> // tsh...@akamai.com
>
> // "One if by land, two if by sea, three if by the Internet."
>
>  
>
>  
>
> *From: *Dennis Clarke 
> *Reply-To: *"openssl-users@openssl.org" 
> *Date: *Friday, August 10, 2018 at 11:40 PM
> *To: *"openssl-users@openssl.org" 
> *Subject: *Re: [openssl-users] About 1.0.2p version release !!
>
>  
>
> On 08/10/2018 08:27 PM, Short, Todd via openssl-users wrote:
>
> RFC 8446 (TLS 1.3) was just published about ~30 minutes ago.
>
>  
>
> Wonderful !
>
>  
>
> Todd are you okay[1] with your name being here :
>
>  
>
>  https://www.tls13.net/ 
>
>  
>
>  
>
> Given that your name is in the maillist I figured .. sure, most likely
>
>   .. but it is best to ask.
>
>  
>
>  
>
> Dennis
>
>  
>
> -- 
>
> 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] 2 openssl installed?

[Wouter Verhelst]

Please contact the support channels of whoever set up that server. If
that was you, try to remember how you configured things when you set
them up, and copy that configuration, including the relevant files.

There are a million ways to implement a PKI service, and the details of
where you need to drop those files on the new server depend greatly on
the choices you've made while configuring things.


On 13-06-18 08:29, sampe...@tiscali.it wrote:
> Yes, that’s right.
> My target is to migrate old server to new one keeping PKI and certificates 
> (included databases).
> After this search how can I manage these files into new server?
> I Should to create multiple directory ? Each one for each index.txt files ? 
> My search found several index.txt files
> It’s necessary to write this directory immediately under openssl directory?
>
>
>> On 12 Jun 2018, at 18:30, Jan Just Keijser  wrote:
>>
>> Hi,
>>
>> On 07/06/18 06:14, Sampei wrote:
>>> t’s a server installed many many years ago and there are applications which 
>>> are no used.
>>> Server is too late and I have new server (latest Centos 6) for migrating 
>>> where I installed latest version.
>>> I’d like to take to new server all certificate database (certificated 
>>> included) which I created.
>>> Openssl is only tool to create test certificates.
>>> I don’t know if there are apps which are using the e configs, but I think 
>>> no.
>>>
>> this has little to do with OpenSSL itself and more with PKI management. 
>> Basically, your problem seems to be that you have an older server and you 
>> don't know where the certificates and private keys (i.e. the PKI) were 
>> stored. What you need to do, is find out where the certifcates are held, 
>> together with the index.txt file. In order to do so, you could use something 
>> like
>>   find / -name '*.pem'
>> or
>>   find / -name index.txt
>> and check all directories where such files are found. This will be a lengthy 
>> process, as the find command has to traverse the entire filesystem.
>>
>> good luck,
>>
>> JJK
>>

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

Re: [openssl-users] Need help regarding openssl errror

[Wouter Verhelst]

This type of error message is shown when the error strings haven't been
loaded. You can fix that by way of the ERR_load_crypto_strings() call.


On 08-03-18 14:14, binod kumar via openssl-users wrote:
> Hello openssl users,
>
> Need you help understanding the openssl error
> "*error:140760FC:lib(20):func(118):reason(252)*".  I am using SSL
> server on Windows machine and am successfully able to connect and make
> requests to this server from other Windows machine. 
> But when requests are being made with same set of certificates  from
> Solaris amd 64 machine I am getting this error.
>
> While debugging I identified that this error is being thrown by SSL
> server during SSL_accept() call.
>
> I tries searching about this error on Web but could not find
> meaningful answer. Please help me understand the issue and fix it or
> point me to the right forum where I can get answer for this.
>
> Thanks & Regards,
> Binod Kumar
>
>
>

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

Re: [openssl-users] Building OpenSSL from sources

[Wouter Verhelst]

Hi Dmitry,

On 15-02-18 09:00, Dmitry Belyavsky wrote:
> Hello,
>
> I get problems building and installing OpenSSL 1.1.0g from source. I
> use Debian Wheezy (oldstable).
>
> After running ./config; make; make test; sudo make install 
>
> I call  /usr/local/bin/openssl 
>
> I get an error 
>
> /usr/local/bin/openssl: error while loading shared libraries:
> libssl.so.1.1: cannot open shared object file: No such file or directory
>
> $ ldd /usr/local/bin/openssl 
>         libssl.so.1.1 => not found
>         libcrypto.so.1.1 => not found
>
> This behavior differs from the one for version 1.1.0b, where
> everything works fine. 
>
> According to CHANGES in 1.1.0c
>
>  *) Removed automatic addition of RPATH in shared libraries and
> executables,
>      as this was a remainder from OpenSSL 1.0.x and isn't needed any more.
>      [Richard Levitte]
>
> Could you please clarify why this changes were introduced?

RPATH has certain semantics which are unexpected for some users (e.g.,
copying files around and updating ld.so.conf won't work). They have
their uses, but a build system using them *by default* is not
necessarily a good idea.

> Shouldn't the INSTALL file be changed to document this change 
> because the proposed way (  ./config; make; make test; make install)
> does not work?

It should, but you may have to check your dynamic linker configuration
to make sure that the library in which libssl is installed is found in
your library search path.

Check /etc/ld.so.conf (and directories included from that file, if any)
to make sure that it contains the directory where libssl.so ends up. If
it does not, add it, and then run 'ldconfig' without arguments to update
the cache.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Wouter Verhelst]

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Wouter Verhelst]

On 31-10-17 17:47, Matt Caswell wrote:
> 
> 
> On 31/10/17 16:42, Wouter Verhelst wrote:
>> On 31-10-17 17:26, Matt Caswell wrote:
>>> I agree its not a great name for it. Unfortunately we are stuck with it
>>> for compatibility reasons. If we renamed it we would break any code that
>>> is currently using it. We could introduce a new flag with a different
>>> name which does the same thing - but I'm not sure that does anything to
>>> make things less confusing.
>>
>> You could always keep the old name around and mark it deprecated. GCC
>> even has a pragma for that -- __attribute__((deprecated)) -- although I
>> doubt it works on macros (haven't tested that).
>>
>> I suppose it might be too much of an effort for too little gain, though.
>>
> 
> As a matter of policy we won't deprecate anything more until we do a
> 1.2.0 release.

That's a sensible policy, thanks.

> If someone wants to create a PR for a new name for this (defining the
> old one to point at the new one), then I'd review it. But if we're going
> to go to that effort then we should write the documentation as part of
> the PR (there seems little sense to me in replacing an undocumented name
> which you have to read the source to understand with another
> undocumented name that you also have to read the source to understand).

As I ran into this when reviewing how to do OCSP, but ended up not
needing it (I need normal path validation within a limited set of root
certificates), I might look into doing that if/when I find the time for
it some time soon.

Thanks,

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Wouter Verhelst]

On 31-10-17 17:26, Matt Caswell wrote:
> I agree its not a great name for it. Unfortunately we are stuck with it
> for compatibility reasons. If we renamed it we would break any code that
> is currently using it. We could introduce a new flag with a different
> name which does the same thing - but I'm not sure that does anything to
> make things less confusing.

You could always keep the old name around and mark it deprecated. GCC
even has a pragma for that -- __attribute__((deprecated)) -- although I
doubt it works on macros (haven't tested that).

I suppose it might be too much of an effort for too little gain, though.

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Wouter Verhelst]

Hi Matt,

On 31-10-17 16:36, Matt Caswell wrote:
> Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final
> "flags" argument? This basically finds the signer certificate and
> verifies the signature using OCSP_BASICRESP_verify(), but skips all the
> chain validation bit.
Just wanted to point out that that is, actually, a confusing name for
that flag.

"NOVERIFY" seems to imply that there is no verification being done, at
all. Intuitively one senses that's not right, and that at least some
verification will be done (in casu the signature will still be checked);
but figuring out which part of the verification is being dropped and
which part isn't requires one to read either the library source or the
documentation, both of which are annoying if they can be avoided and do
not help for the readability of code that uses the flag in question.

Might I suggest that this flag be renamed somehow, to something that
makes it more clear what exactly it does?

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

Re: [openssl-users] CRL signature verification

[Wouter Verhelst]

Hi Rich,

On 18-10-17 17:46, Salz, Rich via openssl-users wrote:
> ➢ I used libcrypto to parse out the OCSP URL from the certificate validate
> it against a whitelist of valid OCSP URLs, send an OCSP request and
> validate the response and its signature against a custom certificate
> store, and then parse out the result.
> 
> Two points on that:
> ➢ - This seems like something that should be in libcrypto rather than in
> my own code. Did I miss something obvious?
> 
> We generally don’t do any kind of network traffic (except SSL) and would 
> rather leave that up to the application.  Especially because there are all 
> sorts of other frameworks, blocking issues, DNS, etc., that make things a 
> non-simple matter.

Sorry, I should have been clearer.

I didn't mean the HTTP requests etc. I agree that that should not be
done by libcrypto.

I was more talking about the parsing. Currently I have 40 LOC [1] to
find the OCSP URL from a certificate; it seems to me that that's a lot
of stuff that I shouldn't have to be doing, and that asking OpenSSL to
parse out that URL (or really, any other X.509v3 extension's data)
should not be too complicated.

Perhaps I missed the call that I should have been using, though ;-)

[1]
https://github.com/Fedict/eid-mw/blob/master/plugins_tools/eid-viewer/verify.c#L89-L129

> ➢ - Currently I don't fall back to CRLs when the OCSP server is
> unavailable. I would like to do so; however, I can't figure out how to
> validate the signature on a CRL (which would be a pretty obvious
> failure). Alternatively, is there an obvious alternative thing that I
> should be doing, rather than manually parsing the CRL?
>   
> X509_CRL_verify.  And yes, looking through to find the serial# is what you 
> have to do.

That's 1.1-specific, correct?

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

[openssl-users] CRL signature verification

[Wouter Verhelst]

Hi,

I have an application which wants to do verification of a certificate.
Not in the context of a context or a signature, but simply to verify if
the certificates are still valid and from a source that is correct in
the context in which the application runs.

I used libcrypto to parse out the OCSP URL from the certificate validate
it against a whitelist of valid OCSP URLs, send an OCSP request and
validate the response and its signature against a custom certificate
store, and then parse out the result.

Two points on that:
- This seems like something that should be in libcrypto rather than in
my own code. Did I miss something obvious?
- Currently I don't fall back to CRLs when the OCSP server is
unavailable. I would like to do so; however, I can't figure out how to
validate the signature on a CRL (which would be a pretty obvious
failure). Alternatively, is there an obvious alternative thing that I
should be doing, rather than manually parsing the CRL?

Thanks,

-- 
Wouter Verhelst
-- 
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

[Wouter Verhelst]

On 08-10-17 22:55, Thomas J. Hruska wrote:
> On 10/8/2017 7:28 AM, Michel wrote:
>> While I understand that using non-blocking descriptors is a better
>> practice,
>> I still do not see why select() should NEVER be used for blocking sockets
>> (except when combined/interfered with the internal OpenSSL state
>> machine or
>> equivalent mechanism).
>>
>> Could you please elaborate or give an example ?
>>   Regards,
>>
>> Michel.
> 
> Example:  You call select(), it returns the descriptor as readable, you
> pass it into SSL_read(), and SSL_read() blocks.  You are worse off than
> before you used select() since you made the incorrect assumption that
> you could do something when select() returns and not have a blocking
> socket block.
> 
> Just because select() says that something is readable (or writable) does
> not actually make it so.

Er, yes it does. Perhaps not as much as you wanted, but yes there will
be something there.

> The function only makes sense for non-blocking
> descriptors.  The use of select() with a blocking descriptor is always
> wrong.

Er, no it isn't.

Example: you select() on all your file descriptors in your main thread.
When select() tells you that one of them is ready to read, you fire off
a message to a thread pool and have one of the worker threads in that
thread pool (eventually) handle reading your data in a blocking manner.
Once the thread from the thread pool has finished reading, it will start
work on another file descriptor. This allows you to serve more clients
than you have threads, so allows to avoid overloading your server, but
since you use blocking I/O on your file descriptors you can get away
with not having the extra complexity of the state machine that blocking
I/O requires.

You can't implement that properly without doing select() on blocking
file descriptors, however.

> Non-blocking code is actually easier to implement than you think.

It isn't too hard, to write, that's true. It's more difficult to reason
about and to avoid bugs with, however (and for thread pools, you just
use a library -- e.g., GThreadPool from libglib).

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

Re: [openssl-users] PKCS7 and RSA_verify

[Wouter Verhelst]

On 28-09-17 01:19, ch wrote> If the pkcs-signature is binary encoded it
is not working for verifiying
> a SMIME-message in my experience with
> smime or cms-smime on the console. I tried to convert the binary ones to
> base64 but that does not everytime the trick.

What you call "base64" is commonly known as "PEM" :-)

You can get it to parse binary, but to do so you need to specify
"-inform der".

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

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

[Wouter Verhelst]

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

Re: [openssl-users] Self signed cert issue

[Wouter Verhelst]

On 15-09-17 15:58, Richard Olsen wrote:
> I missed putting in the email  that i created all the certs as listed
> below. SO i have the CA, Server and Client certs created. And tried to
> do the pfx file for authentication with a "Soft cert" where i'll have to
> configure later for a "hard cert" smartcard.

Okay, so what are you trying to do, then?

- If you're trying to do client-side authentication, then you need to
place your CA certificate in a file that you point to with
SSLCACertificateFile (see
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslcacertificatefile
for the apache 2.2 version of that configuration item). The Server
certificate can be any (and should probably be a public-trust one).
- If you're trying to authenticate your server against a private CA,
then you should import the private CA certificate into your browser
trust store. For firefox, you do that by going to Preferences ->
Advanced -> View Certificates -> Authorities -> Import..., and then
pointing to the .crt file.

Note that while it is allowed, it is absolutely not necessary that your
server certificate and client certificate are from the same CA.

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

Re: [openssl-users] Self signed cert issue

[Wouter Verhelst]

On 15-09-17 15:24, Richard Olsen wrote:
> "host.local.com <http://host.local.com> uses and invalid security
> certificate. The certificate is not trusted because the issuer
> certificate is unknown. The server might not be sending the appropriate
> intermediate certficates. An addistional root certificate may need to be
> imported>
> Error code"SEC_ERROR_UNKNOWN_ISSUER"

This is the normal message you get from firefox when your certificate is
self-signed. It appears because firefox doesn't know the certificate
issuer (obviously), and is important so as to avoid an MITM attack.

You have three options:

- (preferred) use something like letsencrypt to get a public-trusted
certificate (although obviously that won't work if your site is not on
the public Internet)
- Create your own private CA that you then import as trusted into the
browsers on your network (rather a lot of work, but probably the better
option if this isn't just a home experiment)
- Tell Firefox to ignore the fact that it's a self-signed certificate by
clicking on the "Add exception..." button. In the dialog that appears,
make sure that the "Permanently store this exception" option is checked,
and hit "Confirm security exception". You will need to do this on every
machine that wants to connect to your server, for every certificate that
you create in this way, which may be a lot of work; if you don't want
that, see above.

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

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

[Wouter Verhelst]

On 16-08-17 15:24, Tom Browder wrote:
[...]
> 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).

You should revoke certificates when their private keys are compromised;
e.g., when the machine on which they were stored is stolen, lost, or
broken into by a remote attacker based on password guessing, user error,
social engineering, or something of the sorts. You aren't sure that any
of that will happen now, but usually people who are compromised never
expected that. Don't assume that just because they are
password-protected that they are safe; passwords will delay the
attacker, but not stop them.

To accomodate for that, you should generate the CRLs for your
certificates now, even if they're empty, and make sure that the software
you've configured to use your private CA are set up check the CRLs. That
way, when you become aware of a compromised private key of one of the
certificates, you don't need to hurry to reconfigure all those services,
but can simply revoke the certificate and possibly force critical
applications to reread the CRL (e.g., by restarting the service),
thereby turning a possibly full-day panicked "help I was compromised"
into a five-minute "certificate revoked, done" session.

> So, in summary, do I need to ensure cert serial numbers are unique for
> my CA?

Since CRLs expect that your serial numbers are unique, yes, you do need
to ensure that.

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

Re: [openssl-users] Rejecting SHA-1 certificates

[Wouter Verhelst]

On 11-07-17 23:44, Salz, Rich via openssl-users wrote:
>> It's very well worth the effort, otherwise there's a security issue, because 
>> certificates can be forged.
> 
> No they cannot.
> 
> What *has* been done is a document was created with "weak spots" and another 
> document was created that  changed those weak spots, but the digest was the 
> same.

Correct me if I'm wrong, but wasn't the MD5 certificate hack presented
back at 25C3 based on exactly that scenario? They used the serial number
and timestamp or some other such thing (don't recall the details) as
weak spots and then sent loads of certificate requests to the CA to
effecively brute-force it.

(Of course, CAs are now required to randomize their serial number, so
since that particular attack isn't possible anymore, I agree that for
the time being it's still not a feasible scenario for SHA1, but hey)

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

Re: [openssl-users] OpenSSL version 1.0.2l published

[Wouter Verhelst]

On 02-06-17 03:18, Viktor Dukhovni wrote:
> 
>> On Jun 1, 2017, at 10:54 AM, Wouter Verhelst <wouter.verhe...@fedict.be> 
>> wrote:
>>
>> It might be useful to make that point at the start of the CHANGES file,
>> then. Currently, it just says "Changes between X.Y.Zx and X.Y.Zy
>> [date]". While that doesn't claim to be complete, the simple word
>> "CHANGES" invokes the idea of a changelog, which should be complete --
>> and this file is not. If it's not meant to be, fine -- but then it
>> doesn't hurt to say so, and it would alleviate some confusion.
> 
> Sure, would "Major changes" be sufficient?  This is essentially
> a RELEASE_NOTES file, not a comprehensive change log, which is
> subsumed by git.

Something like that, yes.

Alternatively, a note saying "and a number of changes too small to be
noted here, please see the git log for details" at the end of every
changelog would work too (and give a hint to users where to go for more
details).

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

Re: [openssl-users] OpenSSL version 1.0.2l published

[Wouter Verhelst]

On 01-06-17 16:40, Matt Caswell wrote:
> CHANGES is what it is - a list of changes we thought were particularly
> worthy of note. If that's not enough information for you then use the
> git logs. I see very little value in automatically extracting info out
> of the logs and including it in the distribution when the logs are so
> easily accessible elsewhere.

It might be useful to make that point at the start of the CHANGES file,
then. Currently, it just says "Changes between X.Y.Zx and X.Y.Zy
[date]". While that doesn't claim to be complete, the simple word
"CHANGES" invokes the idea of a changelog, which should be complete --
and this file is not. If it's not meant to be, fine -- but then it
doesn't hurt to say so, and it would alleviate some confusion.

Thanks,

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

Re: [openssl-users] OpenSSL and RPATH's

[Wouter Verhelst]

On 31-05-17 17:11, PGNet Dev wrote:
> On 5/31/17 3:16 AM, Wouter Verhelst wrote:
>> On 30-05-17 18:12, PGNet Dev wrote:
>> [...]
>>> with lots of apps still not at all v110
>>> compatible, or at best broken in their attempts, having local builds of
>>> both v110x and v102x is extremely useful -- and RPATH'ing makes that
>>> trivially manageable.
>>
>> That's exactly my point -- you don't need to use RPATH to handle that
>> (very common) case. You just need to link against the correct .so file
>> at compile time (which can be handled by installing them in separate
>> directories and using -L to specify which one to link to); the runtime
>> dynamic linker will then find a v1.1 version of OpenSSL for applications
>> compiled against 1.1.0x, or a v1.0.2 version for applications compiled
>> against 1.0.2x. It's that simple.
>>
>> RPATH is useful if the SONAME is the same but the libraries aren't, for
>> whatever reason (e.g., local patches). Other than that, you don't need
>> it, 
[...example...]
>> and it's generally a bad idea.
> 
> And, IMO, that's just bad advice.  RPATH is perfectly fine, and this^ is 
> exactly what it exists for.  Feel free to use it or not, but don't FUD 
> perfectly legitimate functionality as a 'bad idea'.

You're quoting me out of context.

I said "Other than that, [...] it's generally a bad idea". I didn't say
"it's always a bad idea", nor did I imply that.

I also said "RPATH is useful if the SONAME is the same but the libraries
aren't". Your example (snipped for brevity) is an example of exactly
that. So we're in agreement?

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

Re: [openssl-users] OpenSSL and RPATH's

[Wouter Verhelst]

On 30-05-17 18:12, PGNet Dev wrote:
[...]
> with lots of apps still not at all v110
> compatible, or at best broken in their attempts, having local builds of
> both v110x and v102x is extremely useful -- and RPATH'ing makes that
> trivially manageable.

That's exactly my point -- you don't need to use RPATH to handle that
(very common) case. You just need to link against the correct .so file
at compile time (which can be handled by installing them in separate
directories and using -L to specify which one to link to); the runtime
dynamic linker will then find a v1.1 version of OpenSSL for applications
compiled against 1.1.0x, or a v1.0.2 version for applications compiled
against 1.0.2x. It's that simple.

RPATH is useful if the SONAME is the same but the libraries aren't, for
whatever reason (e.g., local patches). Other than that, you don't need
it, and it's generally a bad idea.

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

Re: [openssl-users] sha256 digest support in v102l build missing; present in v110f. missing build flag?

[Wouter Verhelst]

On 30-05-17 17:25, Salz, Rich via openssl-users wrote:
>> The results are both functional, but the v102l build is missing
>> sha{224|256|384|512} digests
> 
> Right; those digests are not in 1.0.2

They are, they're just not advertised:

$ openssl version
OpenSSL 1.0.2k  26 Jan 2017
$ openssl help
[...]
Message Digest commands (see the `dgst' command for more details)
md4   md5   mdc2  rmd160
sha   sha1
[...]
$ openssl dgst -sha256 .bash_history
SHA256(.bash_history)=
b8f9308c4b9141993b4af1cee6cdffe36339bc2e05c0bf16206f9944f85aa102
$ openssl sha224 .bash_history
SHA224(.bash_history)=
a13d7f83a0dc0dcfb6032cb3cd7c4669958a2fb0e01dbb72c95e1d02

etc.

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

Re: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library)

[Wouter Verhelst]

On 28-05-17 23:51, Jeffrey Walton wrote:
> So what are the problems here that need to be addressed? I think I
> know some of them:
> 
>  1. Build OpenSSL with an RPATH if installed in non-system location
>  2. Build user program with an RPATH if OpenSSL installed in non-system 
> location
>  3. Use another mechanism when Linux RATH not available (OS X, Solaris, 
> friends)

RPATHs have advantages, but they have some major issues, too. For
instance, if for whatever reason you need to move files around so that
things are stored in a different location, suddenly you'll need to
recompile everything -- because the RPATH is a hardcoded location of the
library in use. This is very confusing, and not something that an
average developer will expect.

There is usually no need to hardcode the location of the library in use,
provided the SONAME is configured correctly. Surprise surprise, OpenSSL
actually does that right:

wouter@gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
|grep SONAME
  SONAME   libssl.so.1.0.2
wouter@gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.1
|grep SONAME
  SONAME   libssl.so.1.1

There is no way that ld.so will load libssl1.1 for an application that
is compiled against libssl.so with an SONAME of libssl.1.0.2 -- unless,
of course, you do things like muck about with RPATH and point it to the
wrong version of the library. In that case, you broke it, you get to
keep both pieces.

>  4. External build tools like Autotools and Cmake

Those are set up to assume that if a library has a particular SONAME, it
will be compatible with other versions of that same library. That's
usually the correct assumption.

Ignoring bugs in configure.ac/Makefile.am and/or CMakeLists.txt files
(those are just code too, you know), IME autotools and CMake usually
just DTRT, by simply using things like pkg-config to produce the correct
-I and/or -L search paths. If you insist on not using them though,
that's also possible:

%.o: %.c
$(CC) -o $@ -c `pkg-config --cflags openssl` $^

target: foo.o bar.o baz.o
$(CC) -o $@ `pkg-config --libs openssl` $^

The only reason why you would ever want to use RPATH with OpenSSL is
because you need to install a particular old version of libssl (or
libcrypto) that has the same SONAME as the system-default, but where you
don't want to use that system-default one -- but why would you want to
do that? Security updates are a good thing, usually.

RPATH support is nice for corner cases, but it should not be the
default, ever.

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

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Wouter Verhelst]

On 27-04-17 13:01, Wouter Verhelst wrote:
> On 27-04-17 12:56, mahesh gs wrote:
>> Hi,
>>
>> We are using Openssl for establish a secure communications for both
>> TCP/SCTP connections.
>>
>> In our application it is possible that remote end forcefully disconnect
>> the connection due to which 
>>
>> SSL_Write raises a SIGPIPE which we want to suppress. Does openssl 
>>
>> provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP socket
>> layer) ?
>>
>> Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE"  as it is
>> not supported by LINUX 
> 
> You want to set the socket to nonblocking:
> 
> flags = fcntl(socket, F_GETFL, 0);
> flags |= O_NONBLOCK
> fcntl(socket, F_SETFL, flags);
> 
> (You'll need to add error checking for the fcntl() calls)

Actually, I confused two different issues here. Ignore me :-)

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

Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write

[Wouter Verhelst]

On 27-04-17 12:56, mahesh gs wrote:
> Hi,
> 
> We are using Openssl for establish a secure communications for both
> TCP/SCTP connections.
> 
> In our application it is possible that remote end forcefully disconnect
> the connection due to which 
> 
> SSL_Write raises a SIGPIPE which we want to suppress. Does openssl 
> 
> provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP socket
> layer) ?
> 
> Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE"  as it is
> not supported by LINUX 

You want to set the socket to nonblocking:

flags = fcntl(socket, F_GETFL, 0);
flags |= O_NONBLOCK
fcntl(socket, F_SETFL, flags);

(You'll need to add error checking for the fcntl() calls)

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

Re: [openssl-users] Escaped Issuer/Subject

[Wouter Verhelst]

On 11-04-17 10:56, c.hol...@ades.at wrote:
> Hi!
> 
> Is it possible to get the distinguished name of issuer or subject in a
> escaped form out of the box?

Escaped for what? XML? SQL? HTML? Shell scripts? Maybe something else?

"Escaped form" isn't something that exists as a generic term. If you
want a string escaped, you're going to have to use some string escape
function of whatever it is you're trying to escape for; e.g., the
database or XML library you're using (you *are* using a library to
generate a structured format, are you?). Otherwise you're going down the
PHP "addslashes" pitfall, which won't help you nor anyone else.

Regards,

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

Re: [openssl-users] PKCS#7

[Wouter Verhelst]

On 15-03-17 05:13, valéry wrote:

Hi,

thank you very much for your response.
Say someone would be able to gather several clear text AES keys and
their respective asymmetrically encrypted RSA blocks. Would it weakens
the security of the RSA key pair ? I mean could it be easier for someone
using that information to brute force an RSA key pair ?


Think of it this way:

As far as the RSA algorithm is concerned, the AES keys are just data. 
They happen to be AES keys, but they might have been a hash value, an 
image, or somebody's date of birth.


If getting the cleartext as well as the encrypted text for an RSA 
message would allow you to more easily guess the RSA key, then the RSA 
algorithm would be seriously flawed.


There is no known attack against RSA for which this is true, however, as 
Rich pointed out.


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

Re: [openssl-users] Should I / How to remove expired certificates from CRL

[Wouter Verhelst]

On 09-02-17 10:58, PM Extra wrote:

Should I remove expired certificates from CRL？


No. The date of the revocation, which can be found in the CRL, is still 
relevant for checking when older certificates were revoked, in case you 
ever need to check signatures on older messages.


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

Re: [openssl-users] After building 1.0.2h , ldd output shows current version as 1.0.0. How to CHange this , Why is this so ?

[Wouter Verhelst]

Hi Ishan,

On 03-11-16 12:29, Ishan Thakur wrote:

Hi ,

When I run "otool -L in MAC" , or "ldd in linux" machines I get the _current version_ of 
OpenSSL as 1.0.0 but I have built OpenSSL v1.0.2h , how to change this "current version" in the 
libraries.

$  otool -L ./libssl.dylib
   libssl.1.0.0.dylib (compatibility version 1.0.0, _current version 1.0.0_)


You should NOT confuse the shared library version with the version of 
the software package. The two are not related (except when the 
developers misunderstand how library versioning works), and trying to 
keep the two in sync is bound to make things break.


For more information, see 
<https://www.akkadia.org/drepper/dsohowto.pdf>, §3.3.


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

[openssl-users] openssl crl fails to parse a CRL file, which seems correct

[Wouter Verhelst]

Hi,

(this is a resend because my MUA crashed while I tried to send this mail 
earlier. If you get it twice, my apologies)


When I try to parse some of the CRLs at <http://crl.eid.belgium.be/>, I 
sometimes get this error:


wouter@gangtai:~$ openssl version
OpenSSL 1.0.2h  3 May 2016
wouter@gangtai:~$ openssl crl -in eidc201203.crl -inform der -noout -text
unable to load CRL
140694432685592:error:0D09E09B:asn1 encoding 
routines:X509_NAME_EX_D2I:too long:x_name.c:203:
140694432685592:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:697:Field=issuer, Type=X509_CRL_INFO
140694432685592:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 
error:tasn_dec.c:697:Field=crl, Type=X509_CRL


This isn't the case for all of the CRLs, just for some of them; e.g., 
everything works fine for eidc201503.crl


However, if I try the same on another machine nearby, which has a much 
older version of OpenSSL, then things seem to work fine:


eidmac:~ buildslave$ openssl version
OpenSSL 0.9.8zh 14 Jan 2016
eidmac:~ buildslave$ openssl crl -in eidc201203.crl -inform der -noout 
-text | head

Certificate Revocation List (CRL):
 Version 2 (0x1)
 Signature Algorithm: sha1WithRSAEncryption
 Issuer: /C=BE/CN=Citizen CA/serialNumber=201203
 Last Update: Sep 14 10:22:50 2016 GMT
 Next Update: Sep 21 10:22:50 2016 GMT
 CRL extensions:
 X509v3 Authority Key Identifier:
 keyid:7A:5F:3A:FF:2D:46:91:90:53:3F:BB:91:2D:29:82:ED:BB:78:6A:E0

This machine is a mac running OSX 10.11, the OpenSSL is the default as 
shipped with that OS; the other is my personal laptop, which runs Debian 
unstable (and the openssl is again the default). I've reproduced the 
same issue on Debian stable, haven't tried much else yet.


I've been trying to figure out why my OpenSSL fails to parse the CRL, 
whereas others do not,. Any hints would be greatly appreciated.


Thanks,

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

Re: [openssl-users] good riddance to PayPal

[Wouter Verhelst]

On 13-05-16 16:56, Steve Marquess wrote:

We have considered this approach, in detail, and the comfort level isn't
there. A requirement of their 501(c) status for such organizations is
that they can't make any commitments as to how funds raised in our name
will be spent.


AIUI, the reason for that is solely that they cannot agree to make any 
payments that could be considered to be illegal. This is for obvious 
reasons; other than that, SPI does not set any rules on what member 
projects choose to do with their funds:


  "Member projects are free to use the funds allocated to them at their
   descretion, as long as such usage is consistent with U.S. laws and
   regulations, and within the constraints of SPI's certificate of
   incorporation and bylaws"

(from http://spi-inc.org/donations/)

The certificate of incorporation and bylaws do not seem to impose any 
further restrictions--but don't take my word for it (they're both 
available on their website).



We would have to trust their good judgment in deciding
how those funds were used.


Actually, as a member project, you would gain the right to vote or stand 
for election in SPI's internal elections, and in doing so would be able 
to exert influence over SPI's decisions.


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

[openssl-users] X509_ALGOR_get_md?

[Wouter Verhelst]

Hi,

I note that OpenSSL provides a function X509_ALGOR_set_md() to set the 
message digest algorithm to be used on a signature, but it doesn't seem 
to provide a corresponding X509_ALGOR_get_md() function.


Is this correct, or did I miss something? If I didn't miss anything, 
then how can I figure out which hashing algorithm was used for a given 
X.509 certificate?


Thanks,

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

Re: [openssl-users] OCSP_response_status

[Wouter Verhelst]

On 05-01-16 21:23, rosect...@yahoo.com wrote:

Hi, I am using OCSP_response_status(..) to check the OCSP result. My
openssl is of version 1.0.1h.

It is noticed that if the response has some issue, for example, the ocsp
server can not be contacted and thus the request is timed out (this can
be handled separately.) or if the Responder URL path is not correct, the
call to OCSP_response_status(..) will generate a Segmentation fault.


If you pass incorrect data to OCSP_response_status(), things may go 
wrong. So don't do that, then :-)


Instead, the HTTP library which you use should be able to inform you if 
the HTTP request failed for some reason. When it does, don't call 
OCSP_response_status()...


(also, make sure to call OCSP_basic_verify() before accepting the result 
of OCSP_response_status() at fact value, because the latter checks the 
signature while the former does not).


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

Re: [openssl-users] OCSP signature verification

[Wouter Verhelst]

Hi,

(that other mail on OCSP on this list reminded me of this...)

I've found the answer in the mean time by using a debugger and 
single-stepping through the library...


On 01-12-15 14:58, Verhelst Wouter (Consultant) wrote:

Hi folks,

I'm trying to write an application that needs to verify the validity of data on 
a smartcard. That data is signed with an RSA key for which a certificate exists 
on the card; but if the card is stolen or lost, the certificate will be 
revoked, so I want to ensure that the certificate is valid. I'm doing an OCSP 
request to take care of that.

Since OpenSSL's own OCSP_sendreq_* functions don't support HTTP proxies, I'm 
currently using libcurl to send the request to the OCSP endpoint. This seems to 
work; when I get the reply and use d2i_OCSP_RESPONSE(), then with things like 
OCSP_response_status() and OCSP_resp_find_status() and friends I can manage to 
get the status of the request and a given certificate.

However, that doesn't do signature verification. I believe that I should use 
OCSP_basic_verify() for that, but I'm not entirely sure whether that is the 
case, and if so whether I would need to do some additional checks beforehand. 
Unfortunately, I can't find any documentation on OCSP_basic_verify().

I should note that due to the nature of my needs, I have a rather huge set of 
valid intermediate CAs, but a fairly limited set of root CAs that can be used 
for valid cards (that is, if the signature validates but it wasn't signed by 
any of the CAs under one of my limited set of roots, the card is a forgery and 
should be rejected as invalid).

A few questions:
- Am I right in assuming that OCSP_basic_verify will check the signature on the 
OCSP request?


Answer: yes (verified this by modifying some data in the OCSP response 
data, which caused signature verification to fail)



- In "OCSP_basic_verify(OCSP_BASICRESP *bs, STACK_OF(X509) *certs, X509_STORE *st, unsigned long flags)", I'm not 
entirely certain of what the "st" argument is meant to contain, and can't figure out the "certs" one. Pouring 
over the code, I believe the "st" argument should allow me to limit validation to my set of root certificates, but I 
could be mistaken. As for the "certs" one, I can't understand that one at all. The only thing I can think of is that 
maybe it should contain the issuer certificate that I used for the original request, but then why is it a STACK_OF(X509)* and not 
just an X509*? What am I missing?


Answers:

- The "STACK_OF(X509) *certs" argument should just be bs->certs (i.e., 
the certificates which were sent along with the OCSP response, and which 
contain all certificates required to be able to verify the signature on 
the response as well as its certificate chain). I assume this is done so 
as to retain API compatibility with other certificate verification 
methods (e.g., using CRLs), even though the *certs argument really is 
superfluous (OCSP_basic_verify could just as easily pluck those 
certificates out of the *bs argument).
- The "X509_STORE *st" argument indeed allows me to limit the root 
certificates allowed for valid signatures. By not including the default 
certificate store, I can reject cards that are signed by a different root.


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

Re: [openssl-users] letter 's' in s_client in openssl

[Wouter Verhelst]

On 04-01-16 11:11, Kaushal Shriyan wrote:

Hi,

what does the letter 's' signify in *s_client* in the command "openssl
s_client -servername test.example.com <http://test.example.com> -connect
test.example.com:443 <http://test.example.com:443> -showcerts" ?


The man page starts with:

S_CLIENT(1SSL)OpenSSL S_CLIENT(1SSL)

NAME
   s_client - SSL/TLS client program

So, I'd guess it stands for "SSL". What else? ;-)

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

Re: [openssl-users] OCSP signature verification

[Wouter Verhelst]

On 01-12-15 14:58, Verhelst Wouter (Consultant) wrote:

Hi folks,

I'm trying to write an application that needs to verify the validity of data on 
a smartcard. That data is signed with an RSA key for which a certificate exists 
on the card; but if the card is stolen or lost, the certificate will be 
revoked, so I want to ensure that the certificate is valid. I'm doing an OCSP 
request to take care of that.

Since OpenSSL's own OCSP_sendreq_* functions don't support HTTP proxies, I'm 
currently using libcurl to send the request to the OCSP endpoint. This seems to 
work; when I get the reply and use d2i_OCSP_RESPONSE(), then with things like 
OCSP_response_status() and OCSP_resp_find_status() and friends I can manage to 
get the status of the request and a given certificate.

However, that doesn't do signature verification. I believe that I should use 
OCSP_basic_verify() for that, but I'm not entirely sure whether that is the 
case, and if so whether I would need to do some additional checks beforehand. 
Unfortunately, I can't find any documentation on OCSP_basic_verify().

I should note that due to the nature of my needs, I have a rather huge set of 
valid intermediate CAs, but a fairly limited set of root CAs that can be used 
for valid cards (that is, if the signature validates but it wasn't signed by 
any of the CAs under one of my limited set of roots, the card is a forgery and 
should be rejected as invalid).

A few questions:
- Am I right in assuming that OCSP_basic_verify will check the signature on the 
OCSP request?
- In "OCSP_basic_verify(OCSP_BASICRESP *bs, STACK_OF(X509) *certs, X509_STORE *st, unsigned long flags)", I'm not 
entirely certain of what the "st" argument is meant to contain, and can't figure out the "certs" one. Pouring 
over the code, I believe the "st" argument should allow me to limit validation to my set of root certificates, but I 
could be mistaken. As for the "certs" one, I can't understand that one at all. The only thing I can think of is that 
maybe it should contain the issuer certificate that I used for the original request, but then why is it a STACK_OF(X509)* and not 
just an X509*? What am I missing?

Thanks for any help,


Ping. Anyone?

If this is documented somewhere, feel free to point me to the 
documentation...


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