Re: Listing TLS 1.3 Ciphers

[Richard Moore]

On Wed, 10 Apr 2019 at 17:25, Benjamin Kaduk via openssl-users <
openssl-users@openssl.org> wrote:

> On Wed, Apr 10, 2019 at 12:13:27PM -0400, Dennis Clarke wrote:
>
> > Very odd. I thought that there were more at one point.
>
> The ones with truncated (8-byte) authentication tag are not intended for
> general use and don't make it into the default list.
>

They also don't appear if you explicitly try to list 'All' which is what I
found surprising.

Rich



> -Ben
>

Listing TLS 1.3 Ciphers

[Richard Moore]

Hi All,

I haven't found a way to list the supported openssl ciphers from the
command line (i.e. get the list of potential values for -ciphersuites). I
understand that currently there are only 5 options however this could
change over time, so I wanted to avoid hard coding the list in a script. Am
I missing something?

Thanks

Rich

Re: cURL with openSSL 1.1.1 version

[Richard Moore]

On Tue, 19 Mar 2019 at 07:56, Swamy J-S  wrote:

> Right now my code uses curl library with libcurl4 and gnuTLS as SSL
> backend. Am using many curl options such as CURLOPT_SSL_VERIFYPEER ,
>

If you use gnuTLS as your SSL backend then this is nothing to do with
openssl at all.

Kind Regards

Rich

Re: [openssl-users] Openssl 1.1 / TLS 1.3

[Richard Moore]

On 14 February 2018 at 16:34, Matt Caswell  wrote:

>
>
> On 14/02/18 16:27, Richard Moore wrote:
> > If I run the following:
> >
> >  openssl-1.1.1pre1 ciphers -tls1_3 -v
>
> The man page says this about the "-tls1_3" option:
>
> "In combination with the B<-s> option, list the ciphers which would be
> used if TLSv1.3 were negotiated."
>
> So you need to add "-s". If you do that then you only get the TLSv1.3
> ciphers. It's a little strange that the option is ignored if no -s is
> supplied (you might think supplying -tls1_3 would automatically imply
> -s). But that is the way that all the -tls* options work, so this is
> nothing new in 1.1.1.
>

​I see thanks. That's very confusing, but yeah it seems to be there since
1.1.0. How would you feel about that being the default? I'm a little bit
unclear about what the point of the option is otherwise?

Thanks

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

[openssl-users] Openssl 1.1 / TLS 1.3

[Richard Moore]

If I run the following:

 openssl-1.1.1pre1 ciphers -tls1_3 -v

Then I get lots of ciphers, for example AES128-SHA however the latest draft
TLS 1.3 RFC states:

The list of supported symmetric algorithms has been pruned of all
algorithms that are considered legacy. Those that remain all use
Authenticated Encryption with Associated Data (AEAD) algorithms.

This suggests that the ciphers command isn't working as intended. Should I
file an issue in github?

Cheers

Rich.
-- 
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

[Richard Moore]

On 26 September 2017 at 02:36, Kyle Hamilton  wrote:

> 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.
>
>
​That doesn't change the fact it's banned.​



> 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".
>
>
​There are a lot of other things that would also need addressing to make it
secret /who/ you're talking to. ​It's not something https guarantees right
now. If you'd like it to that would be a whole other discussion.



> (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,
>

​​The CA Security Council and CA/Browser Forum are unrelated organisations.​

Regards

Rich.


> 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.
>

​​
-- 
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

[Richard Moore]

On 22 September 2017 at 15:08, Salz, Rich via openssl-users <
openssl-users@openssl.org> wrote:

> Openssl 0.9.8 is old and obsolete and has security issues; you should
> upgrade.
>
>
>
> But even if you upgrade, the ocsp command will not listen on HTTPS; that
> is not supported.
>
>
>
​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.

Cheers

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

Re: [openssl-users] openssl verify with 1B certificates

[Richard Moore]

Depends what information you need - if you just need a binary valid/not
valid then prune it first then verify. If you want a more fine grained data
set then don't. Write some code  - forking and running openssl verify each
time will be insanely slow - don't do that. I doubt you really have a
billion unique certificates - avoid testing duplicates. Also don't forget
that you really need certificate chains, so I hope you captured the
intermediate certificates too!

Cheers

Rich.

On 30 March 2017 at 18:44, ebe ebe  wrote:

> Hello,
>
> I am a CS graduate student and doing a measurement study regarding the SSL
> ecosystem. I have approximately 1 billion SSL certificates and I would like
> to run openssl verify on each certificate to sift out invalid certificates.
> My major concern, as you might guess, is whether doing this verification is
> feasible given the size of my dataset. An alternative idea I have is to
> replicate the verification steps of openssl. More specifically, I am
> working with a Hadoop infrastructure and I can perform some of the
> verification steps without running into scalability issues (e.g is
> certificate between notBefore-notAfter timestamps, subject key&authority
> key identifier checks). However, with this approach I feel like verifying
> the signature would be a big challenge. Any ideas on how I can tackle these
> problems?
>
> Regards,
> Ceyhun
> --
> 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] OpenSSL with Qt5 on Win7

[Richard Moore]

On 3 November 2016 at 11:59, Peissert, Roland (ext) <
roland.peissert@siemens.com> wrote:

> 3.   Next I download OpenSSL openssl-1.1.0b.tar.gz from here:
> http://www.openssl.org/source
> 
>
>
>
​Qt doesn't support openssl 1.1 currently.

Cheers

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

Re: [openssl-users] Porting to OpenSSL 1.1

[Richard Moore]

Hi Bero,

Just based on the questions it sounds like you might be trying to port Qt.
I've already done this, and the branch is here:
https://github.com/richmoore/qtbase/commits/openssl11

It'll be added as a new backend once the configure changes that are
underway are completed. See
https://wiki.qt.io/Qt_Network_Workshop_2016#OpenSSL for a road map (or ask!)

Regards

Rich.


On 10 October 2016 at 23:56, Bernhard Rosenkraenzer  wrote:

> Hi,
> I'm porting some code to OpenSSL 1.1 -- for the most part, it's going
> well, but there's some things I'm not sure about:
>
> - What replaces a direct access to "sha1_hash" in an X509? (found in Qt
> 5.7)
>
> So far, haven't come up with a proper alternative to this. Should the code
> be refactored to use X509_issuer_and_serial_hash (which isn't quite the
> same, but should still give a unique hash)?
> [this is from qHash -- so the purpose really is to get a unique hash of
> the contents]
>
> - What's the best way to copy an EVP_PKEY?
>
> Also from Qt 5.7:
> rsa = RSA_new();
> memcpy(rsa, EVP_PKEY_get1_RSA(pkey), sizeof(RSA));
> [breaks because sizeof(RSA) is no longer known]
> for EC, there's EC_KEY_dup -- for RSA and DSA, not so much.
>
> - What's the proper successor to NETSCAPE_X509? (from kdelibs4support)
> I presume this (the method KSSLCertificate::toNetscape()) can just be
> deleted because nothing should be using Netscape x509 anymore?
>
>
> Outside of those, all problems I've run into so far were fairly easy to
> solve.
>
> ttyl
> bero
> --
> 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] Disable a cipher suite in openssl.cnf?

[Richard Moore]

On 23 September 2016 at 17:13, Scott Neugroschl  wrote:

> Hi,
>
>
>
> I’m afraid the man page on the conf file is not particularly clear.   I’m
> looking at mitigating CVE-2016-2183 (SWEET32), and am not sure how to
> disable the DES and 3DES suites in the conf file.
>
> Can someone give me a hand?
>
>
>

​You can't disable them in the openssl config file, you should do it in the
cipher suite configuration of the affected application.

Cheers

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

Re: [openssl-users] About no-ssl2

[Richard Moore]

On 16 March 2016 at 22:39, Viktor Dukhovni 
wrote:

> On Wed, Mar 16, 2016 at 11:32:28PM +0100, Michel wrote:
> OpenSSL 1.1.0 has no vestigial SSLv2 code, and so nothing to disable
> with OPENSSL_NO_SSL2.  The "OPENSSL_NO_..." macros specify disabled
> features, not deleted code.
>

​That's the major flaw of the current design of flagging when features are
disabled rather than when they're present. I'm sure you'll get plenty more
reports like this.

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

Re: [openssl-users] About no-ssl2

[Richard Moore]

On 16 March 2016 at 22:58, Viktor Dukhovni 
wrote:

> On Wed, Mar 16, 2016 at 10:52:39PM +0000, Richard Moore wrote:
>
> > On 16 March 2016 at 22:39, Viktor Dukhovni 
> > wrote:
> >
> > > On Wed, Mar 16, 2016 at 11:32:28PM +0100, Michel wrote:
> > > OpenSSL 1.1.0 has no vestigial SSLv2 code, and so nothing to disable
> > > with OPENSSL_NO_SSL2.  The "OPENSSL_NO_..." macros specify disabled
> > > features, not deleted code.
> > >
> >
> > ​That's the major flaw of the current design of flagging when features
> are
> > disabled rather than when they're present. I'm sure you'll get plenty
> more
> > reports like this.
>
> Use feature probing via autoconf, or just:
>
> #if OPENSSL_VERSION_NUMBER < 0x1010L && !defined(OPENSSL_NO_SSL2)
> /* SSLv2 available */
> #else
> /* SSLv2 not available */
> #endif
>
> Better yet, drop support for SSLv2, and then you don't care whether OpenSSL
> provides it or not.
>
>
​SSL2 is simply an example of this issue, the same applies to others eg. it
will no doubt occur in future for NPN since ALPN has replaced it. ​

​The problem is the concept itself since it will require every app to have
coded into it when a given feature was removed should it attempt to support
it when present.

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

Re: [openssl-users] [Question] What are the current secure Configure Parameter?

[Richard Moore]

On 14 March 2016 at 21:19, Oliver Niebuhr 
wrote:

> Am 14.03.2016 um 21:43 schrieb Richard Moore:
> > On 10 March 2016 at 04:42, Oliver Niebuhr  > <mailto:googleers...@oliverniebuhr.de>> wrote:
> ​​
> > I am using OpenSSL from within the Qt Project / QtWebEngine.
> >
> > The Qt Wiki says, the following Parameters are minimum recommended:
> > no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5
> >
> >
> > ​Please could you provide a link since these options are a bit dubious,
> > and don't match what I'd expect as the qtnetwork maintainer. I've looked
> > on the wiki myself and I don't see them.
> >
> > Cheers
> >
> > Rich.
>
> Evening.
>
> The following Link
> https://wiki.qt.io/Compiling_OpenSSL_with_MinGW
>
> (relatively outdated)
> under Section "How to Build" mentions not the no-ssl$ stuff.
>
>
​Yes, the no-ssl2 is fine, but the no-ssl3 seems unlikely to work with many
sites. Also Qt Web Engine uses the chromium network stack so the
requirements are different. I've asked the qtwebengine guys what the score
is.​



> But there was another Link which I can not find anymore - the last time
> I saw it, was around late of Summer 2015. It most likely got deleted
> during one of the "Wiki Cleanup Weeks".
>
> It was definitely not from the Nokia times and it was from a Digia
> Member - sorry my schizophrenic Brain is bad with Names.
>

​I'm afraid without more info I can't look into it - the wiki records the
history but I have to know what to look for.

Never mind.

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

Re: [openssl-users] [Question] What are the current secure Configure Parameter?

[Richard Moore]

On 10 March 2016 at 04:42, Oliver Niebuhr 
wrote:

> Hello.
>
> I am using OpenSSL from within the Qt Project / QtWebEngine.
>
> The Qt Wiki says, the following Parameters are minimum recommended:
> no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5
>

​Please could you provide a link since these options are a bit dubious, and
don't match what I'd expect as the qtnetwork maintainer. I've looked on the
wiki myself and I don't see them.

Cheers

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

Re: [openssl-users] explicitly including other ciphers.

[Richard Moore]

On 2 December 2015 at 17:53, Ron Croonenberg  wrote:

> So the idea is to use an object store on an isolated network and push and
> get objects out of it using https.
>
>
​If network is fully isolated you could use plain text. Using 'https' and
null encryption is basically just pretending to do security.

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

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Richard Moore]

On 18 November 2015 at 17:57, Hubert Kario  wrote:

> On Wednesday 18 November 2015 11:12:59 Benjamin Kaduk wrote:
> > On 11/18/2015 07:05 AM, Hubert Kario wrote:
> > > So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
> > > support both relatively modern TLS with user certificates,
> > > preferably the newest cryptosystems and hashes as well as the
> > > oldest ones that were standardised and used.
> > >
> > > That means that old algorithms MUST remain in OpenSSL as supported
> > > functionality. It may require linking to a specific library to make
> > > the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be
> > > removed from it completely, definitely not before at least 50 years
> > > _after_ they became obsolete and broken.

>
> > There seems to be a logical leap between these two paragraphs.  Why is
> > it necessary that OpenSSL be the only cryptographic library used by
> > CAdES-A/etc. implementations?  Is it in fact even necessary that only
> > a single version of a single cryptographic library be used for such
> > software?
> >
> > While OpenSSL may try to be a general-purpose crypto
> > library, when a software has stringent or unusual crypto
> > requirements, it seems reasonable that such a software may need to
> > involve unusual implementations.
> >
> > I do not believe that OpenSSL has promised anywhere that it will
> > support this sort of use case.
>
> From the main web page of project:
>
>   The OpenSSL Project is a collaborative effort to develop a robust,
>   commercial-grade, *full-featured*, and Open Source toolkit
>   implementing the Transport Layer Security (TLS) and Secure Sockets
>   Layer (SSL) protocols as well as a full-strength *general purpose*
>   *cryptography library* .
>
> (emphasis mine)
>
>
​I think now is the time for those who are going to provide the 50 year
support to step up to the plate then. Saying "oh but we can get it for free
for the next 50 years" doesn't work.

I think your emphasis here is exactly right though, the aim is *general
purpose*​ you are most definitely describing an extremely specialised
purpose that has unusual requirements.

​Cheers

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

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Richard Moore]

On 16 November 2015 at 19:05, Hubert Kario  wrote:

> Example: CAdES V1.2.2 was published in late 2000, the first serious
> attacks on MD2 were not published until 2004. I think it is not
> unreasonable for CAdES-A documents to exist today which were originally
> signed with MD2 while it was still considered secure and that are still
> relevant today, just 15 years later.
>
>
​This doesn't explain why the code needs to exist in future versions of
openssl. The previous ones aren't going to vanish and can be compiled and
used to rescue data in theoretical edge cases like this. You're making it
sound like this is making the data totally inaccessible which is not the
case.

Cheers

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

Re: [openssl-users] s_server (and maybe s_client) misbehaves with binary data

[Richard Moore]

On 2 November 2015 at 15:36, Richard Moore  wrote:

>
>
> On 2 November 2015 at 15:33, Jakob Bohm  wrote:
>
>> On 02/11/2015 16:13, Richard Moore wrote:
>>
>> There have always been special commands making s_client unsuitable for
>> this usage - for example R followed by a newline will renegotiate, and Q
>> will quit. According to the docs these can be disabled by -quiet
>> and -ign_eof though I've never tested that myself.
>>
>> Could you point me to where this (non-obvious) relationship
>> between options ostensibly doing something else and the
>> desired effect is documented?  The 1.0.1* man-page of s_server
>> certainly doesn't say that.
>>
>>
> ​It's documented in the s_client man page, but I don't see it in s_server
> (though the commands are listed and it has a few more than s_client).
> Perhaps there is no way to disable them on s_server - I'd have to check the
> code.
>
>
​I've checked the code and -quiet disables them for s_server too.

Rich.
​



> Cheers
>
> Rich.​
>
>
>
>>
>> On 2 November 2015 at 13:37, Jakob Bohm  wrote:
>>
>>> As with most other "apps" in the openssl binary, the s_server
>>> and s_client commands are useful for multiple purposes:
>>>
>>> 1. As debug tools
>>>
>>> 2. As a way to do one-off operations without writing any
>>>   code.
>>>
>>> 3. As back ends for small programs written in scripting
>>>   languages that cannot really call the OpenSSL library
>>>   directly.
>>>
>>> This is about the latter two uses of s_server and s_client to
>>> set up a one-off or scripted secure pipe between two machines.
>>>
>>> Unfortunately, the current (1.0.2) version of s_server will
>>> do special and problematic things when encountering some
>>> 3-byte sequences (such as "\nq\n") in the data stream.
>>>
>>> It would thus be useful for s_server (and if applicable
>>> s_client) to accept the "-binary" option (already provided
>>> by the cms/smime commands), to turn off this behavior and
>>> provide a clean data pass through to/from the other end.
>>> In "-binary" mode, no byte value or sequence of byte value
>>> is special, except that explicit use of the "-crlf" option
>>> still works.
>>>
>>>
>>
>> Enjoy
>>
>> Jakob
>> --
>> Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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] s_server (and maybe s_client) misbehaves with binary data

[Richard Moore]

On 2 November 2015 at 15:33, Jakob Bohm  wrote:

> On 02/11/2015 16:13, Richard Moore wrote:
>
> There have always been special commands making s_client unsuitable for
> this usage - for example R followed by a newline will renegotiate, and Q
> will quit. According to the docs these can be disabled by -quiet
> and -ign_eof though I've never tested that myself.
>
> Could you point me to where this (non-obvious) relationship
> between options ostensibly doing something else and the
> desired effect is documented?  The 1.0.1* man-page of s_server
> certainly doesn't say that.
>
>
​It's documented in the s_client man page, but I don't see it in s_server
(though the commands are listed and it has a few more than s_client).
Perhaps there is no way to disable them on s_server - I'd have to check the
code.

Cheers

Rich.​



>
> On 2 November 2015 at 13:37, Jakob Bohm  wrote:
>
>> As with most other "apps" in the openssl binary, the s_server
>> and s_client commands are useful for multiple purposes:
>>
>> 1. As debug tools
>>
>> 2. As a way to do one-off operations without writing any
>>   code.
>>
>> 3. As back ends for small programs written in scripting
>>   languages that cannot really call the OpenSSL library
>>   directly.
>>
>> This is about the latter two uses of s_server and s_client to
>> set up a one-off or scripted secure pipe between two machines.
>>
>> Unfortunately, the current (1.0.2) version of s_server will
>> do special and problematic things when encountering some
>> 3-byte sequences (such as "\nq\n") in the data stream.
>>
>> It would thus be useful for s_server (and if applicable
>> s_client) to accept the "-binary" option (already provided
>> by the cms/smime commands), to turn off this behavior and
>> provide a clean data pass through to/from the other end.
>> In "-binary" mode, no byte value or sequence of byte value
>> is special, except that explicit use of the "-crlf" option
>> still works.
>>
>>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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] s_server (and maybe s_client) misbehaves with binary data

[Richard Moore]

There have always been special commands making s_client unsuitable for this
usage - for example R followed by a newline will renegotiate, and Q will
quit. According to the docs these can be disabled by -quiet and -ign_eof
though I've never tested that myself.

Cheers

Rich.

On 2 November 2015 at 13:37, Jakob Bohm  wrote:

> As with most other "apps" in the openssl binary, the s_server
> and s_client commands are useful for multiple purposes:
>
> 1. As debug tools
>
> 2. As a way to do one-off operations without writing any
>   code.
>
> 3. As back ends for small programs written in scripting
>   languages that cannot really call the OpenSSL library
>   directly.
>
> This is about the latter two uses of s_server and s_client to
> set up a one-off or scripted secure pipe between two machines.
>
> Unfortunately, the current (1.0.2) version of s_server will
> do special and problematic things when encountering some
> 3-byte sequences (such as "\nq\n") in the data stream.
>
> It would thus be useful for s_server (and if applicable
> s_client) to accept the "-binary" option (already provided
> by the cms/smime commands), to turn off this behavior and
> provide a clean data pass through to/from the other end.
> In "-binary" mode, no byte value or sequence of byte value
> is special, except that explicit use of the "-crlf" option
> still works.
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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] [openssl-announce] Website changing this weekend

[Richard Moore]

On 21 August 2015 at 03:36, Salz, Rich  wrote:

>
> >Many of the changelogs have disappeared - for example try finding the
> changelog between 0.9.8n and 0.9.8o on
> https://www.openssl.org/news/changelog.html. This applies to lots of
> other releases too.
>
> Thanks.
>
> It seems that the 0.9.8n -> 0.9.8o changes are only in the 0.9.8 branch.
> We pull the changelog from master.  Looks like some changelog entries
> didn't get carried over to there.  If you come across others,post and we
> can maybe update master.
>
>
​It seems to be that when a new branch was released then none of the
​subsequent changes for older branches are available. So almost all the
recent 0.9.8 changelogs, and 1.0.0 changelogs are missing.

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

Re: [openssl-users] [openssl-announce] Website changing this weekend

[Richard Moore]

On 14 August 2015 at 21:20, Salz, Rich  wrote:

> We’re bringing up a new website this weekend.  Please be patient if you
> have problems.  If you notice any broken links, let us know.
>
>
>
​Many of the changelogs have disappeared - for example try finding the
changelog between 0.9.8n and 0.9.8o on
https://www.openssl.org/news/changelog.html. This applies to lots of other
releases too.

Cheers

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

Re: [openssl-users] Verifying a signature - format problems

[Richard Moore]

On 27 July 2015 at 17:30, Andrew Carpenter  wrote:

> Thanks again Richard for your help.  I found out that I was using
> std::string::append in my code, and that append stopped reading when it
> reached a NULL byte in the signature(which is a valid byte given the hash
> function) and that was truncating the signature.
>
>
​Glad you got it sorted.

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

Re: [openssl-users] Verifying a signature - format problems

[Richard Moore]

On 24 July 2015 at 19:30, Andrew Carpenter  wrote:

> Well That's interesting.  when I download and use your .sig file, I get
> the same errors.  How do you go about picking up your signature form the
> file system?
>
>
​Nothing special:
https://codereview.qt-project.org/#/c/113855/27/tests/auto/network/ssl/qssl/tst_qssl.cpp,unified
around line 170 for example.

Cheers

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

Re: [openssl-users] Verifying a signature - format problems

[Richard Moore]

On 24 July 2015 at 13:32, Andrew Carpenter  wrote:

> So my question is: What format should the signature file be in?
> base64? DER? PKCS7? raw binary?  Specifically I am talking about the
> function EVP_DigestVerifyFinal(), What format should the *sig parameter be
> in?  The DiestVerifyInit and DigestVerifyUpdate are working with no errors,
> so I have narrowed it down to this function.
> Thanks,
>
>
​You might find this change I've recently written for Qt useful:
https://codereview.qt-project.org/#/c/113855/
It implements exactly this and has lots of test cases.

Cheers

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

Re: [openssl-users] Vulnerability Disclosures

[Richard Moore]

On 12 July 2015 at 03:31, Salz, Rich  wrote:

> I'd be concerned about doing that.  While this one seemed pretty rare --
> only folks running a release less than 30 days old in production -- as a
> general rule, it's impossible to tell.  For example, we THINK that PSK
> isn't used much, but we have no idea -- it's real popular in the Internet
> of Things, for example.  It seems safer to say nothing, then to say
> something misleading or wrong.
>
> We'd like to give as much information as possible, but not enough to
> expose the vulnerability exploit and not anything that could be
> misleading.  It's a very hard point to triangulate.
>

​I don't really see this being feasible. For example many of our clients
get confused when we report openssl vulnerabilities against some SSL
accelerator or proxy device simply because they're unaware that the code in
the device is based on openssl.

Cheers

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

Re: [openssl-users] libtlssep

[Richard Moore]

On 30 June 2015 at 14:55, W. Michael Petullo  wrote:

> and a research prototype at:
>
> https://www.flyn.org/projects/libtlssep/
> The libtlssep website.
>
> We would love to hear any constructive comments you might have, and would
> be interested in hearing about any possibility for future collaboration.
>

​I like the concept of using priv sep. :-)

I haven't had a chance to look at your code properly, but one thing I
noticed from a quick read through the docs was that you're relying on
passing fds to t
lssep_connect
​() that will make it impossible for people to write code that works
through proxies (HTTP, socks etc.) unless you build support into the
library itself. An abstraction along the lines of BIO that provides for
working on buffers would really be needed for this use case.

​Cheers

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

Re: [openssl-users] removing compression?

[Richard Moore]

On 7 April 2015 at 17:49, Jakob Bohm  wrote:

>  It also appears the HTTP/2.0 draft aka SPDY requires
> compression to be enabled, though I don't know if that
> is at the TLS or HTTP level.
>

HTTP/2 does not require TLS compression. It does however use it's own
compression for headers (hpack) which is designed to be safe from attacks
like CRIME.

Cheers

Rich.

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

Re: [openssl-users] Encryption length, OpenSSL_add_all_algorithms, and OpenSSL_add_all_ciphers questions

[Richard Moore]

On 26 March 2015 at 14:53, Philip Bellino  wrote:

>  I am using OpenSSL-1.0.2a EVP routines to encrypt and decrypt passwords
>
> with cipher des_ede3_cbc as follows:
>
>
>
Your design is fundamentally flawed. You should be hashing passwords using
bcrypt, pbkdf or similar not encrypting them.

Regards

Rich.

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

Re: [openssl-users] Getting info on the ciphers supported by a client

[Richard Moore]

On 6 March 2015 at 14:05, Christian Georg <
christian.ge...@cologne-intelligence.de> wrote:

>  The tricky part are the supported cipher suites. When using the -www
> option I can return a website to the client showing the cipher suites that
> provide a match, which gets pretty close to what I want in a browser. Now
> here are my challenges.
>
>
>
Personally I do this with wireshark and simply take a look at what the
client said in the ClientHello.

Cheers

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

Re: [openssl-users] has anyone developed a standalone test for CVE-2014-8730?

[Richard Moore]

I wrote a test using tlslite - only a few lines of code, so it should be
pretty easy to reproduce.

Rich.


On 27 February 2015 at 18:31, Brian Reichert  wrote:

> I've found one on-line tester for CVE-2014-8730 here:
>
>   https://www.ssllabs.com/ssltest/
>
> But, I was looking for an offline test I could perform in our dev
> environment.
>
> Does anyone know of one?  I've had no luck as of yet...
>
> --
> Brian Reichert  
> BSD admin/developer at large
> ___
> 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] [openssl-dev] The evolution of the 'master' branch

[Richard Moore]

On 8 February 2015 at 00:19, Matt Caswell  wrote:

>
>
> On 07/02/15 14:41, Richard Moore wrote:
> >
> >
> > On 3 February 2015 at 22:02, Rich Salz  > <mailto:rs...@openssl.org>> wrote:
> >
> > As we've already said, we are moving to making most OpenSSL data
> > structures opaque. We deliberately used a non-specific term. :)
> > As of Matt's commit of the other day, this is starting to happen
> > now.  We know this will inconvenience people as some applications
> > no longer build.  We want to work with maintainers to help them
> > migrate, as we head down this path.
> >
> > We have a wiki page to discuss this effort.  It will eventually
> include
> > tips on migration, application and code updates, and anything else
> the
> > community finds useful.  Please visit:
> >
> > http://wiki.openssl.org/index.php/1.1_API_Changes
> >
> >
> > I've documented what got broken in Qt by the changes so far. I've listed
> > the functions I think we can use instead where they exist, and those
> > where there does not appear to be a replacement.
>
>
> On the wiki you say this:
>
> "cipher->valid - we were directly accessing the valid field of
> SSL_CIPHER. No replacement found."
>
> I'm just trying to work out why you need this? As far as I can tell from
> the code the only time valid isn't true is for cipher aliases ("ALL",
> "COMPLEMENTOFALL" etc)...but I thought these were only used as an
> SSL_CIPHER internally. E.g. if you call SSL_get_ciphers() then you only
> get valid ciphers I think??
>
> What scenario do you have where you are seeing ciphers that aren't valid?
>

Excellent question. This is code I inherited, and I can't see a sane reason
why the cipher might not be valid. I strongly suspect removing this bit of
code is actually the right solution here. The code is at
http://code.woboq.org/qt5/qtbase/src/network/ssl/qsslsocket_openssl.cpp.html#651

Maybe some edge case for things like the TLS_FALLBACK_SCSV could have an
effect, but even then I can't see how it would relevant to the code that's
actually doing this.

Cheers

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

Re: [openssl-users] [openssl-dev] The evolution of the 'master' branch

[Richard Moore]

On 7 February 2015 at 17:22, Dr. Stephen Henson  wrote:

> On Sat, Feb 07, 2015, Richard Moore wrote:
>
> >
> > I've documented what got broken in Qt by the changes so far. I've listed
> > the functions I think we can use instead where they exist, and those
> where
> > there does not appear to be a replacement.
> >
>
> For the DH case could you store the encoding of the DHparams structure and
> call d2i_DHparams instead? That should work on all versions of OpenSSL
> including 1.1.
>

Good idea, yes that should work for us.

Cheers

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

Re: [openssl-users] [openssl-dev] The evolution of the 'master' branch

[Richard Moore]

On 3 February 2015 at 22:02, Rich Salz  wrote:

> As we've already said, we are moving to making most OpenSSL data
> structures opaque. We deliberately used a non-specific term. :)
> As of Matt's commit of the other day, this is starting to happen
> now.  We know this will inconvenience people as some applications
> no longer build.  We want to work with maintainers to help them
> migrate, as we head down this path.
>
> We have a wiki page to discuss this effort.  It will eventually include
> tips on migration, application and code updates, and anything else the
> community finds useful.  Please visit:
>
> http://wiki.openssl.org/index.php/1.1_API_Changes


I've documented what got broken in Qt by the changes so far. I've listed
the functions I think we can use instead where they exist, and those where
there does not appear to be a replacement.

Cheers

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

Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others

[Richard Moore]

On 23 January 2015 at 17:22, Salz, Rich  wrote:

>  Thanks for the links.  I understand it's a real issue.  The concern is
> will windows return EACCESS for cases when there really is access denied?
>
>
No, if it's file permissions you get EPERM. EACCESS is weirder things like
opening a directory fopen(), see
https://msdn.microsoft.com/en-us/library/5814770t.aspx

Cheers

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] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others

[Richard Moore]

The ones I can find are:
http://rt.openssl.org/Ticket/Display.html?id=3263
http://rt.openssl.org/Ticket/Display.html?id=2644
http://rt.openssl.org/Ticket/Display.html?id=3488

Two  which seem to be suggesting the same fix. I'm also aware of bugs in
the Qt bug tracker, my work's internal bug tracker and the curl bug tracker
as a result of this, so I know it's not just a theoretical issue.

Cheers

Rich.

On 23 January 2015 at 16:14, Salz, Rich  wrote:

> > There's been a patch that's been ignored in the bug tracker for ages to
> at least minimise this problem on Windows by treating EACCESS the same as
> EPERM to handle the case of removable disks.
>
> Do you know the ticket number?  I vaguely recall it but can't find
> immediately find it.  I know when I looked at it I had cross-platform
> concerns.
>
> --
> Principal Security Engineer, Akamai Technologies
> IM: rs...@jabber.me Twitter: RichSalz
> ___
> 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] missing default /usr/local/ssl/openssl.cnf causes failure on AIX, warning on all others

[Richard Moore]

On 23 January 2015 at 15:04, Michael Wojcik 
wrote:

> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> > Of Koehne Kai
> > Sent: Friday, January 23, 2015 04:03
> > To: openssl-users@openssl.org
> > Subject: Re: [openssl-users] missing default /usr/local/ssl/openssl.cnf
> causes
> > failure on AIX, warning on all others
> >
> > This reminds me of
> > http://rt.openssl.org/Ticket/Display.html?id=2644&user=guest&pass=guest
> ,
> > though it's in another code path ... Over time I met at least 4 other
> people
> > who ran into exactly this issue on Windows, so if I'd have any votes to
> give to
> > a bug report, it would be this one :)
>
> This is an interesting one because the problem is clear - the openssl
> utility exits if it gets any error other than "file doesn't exist" trying
> to open its configuration file - but the solution is not.
>
>
The real problem isn't with openssl the utility. The problem (and it's a
major one) is that this behaviour occurs when using openssl as a library
and causes the application using openssl to terminate. This is appallingly
bad practice for a library.


> [snip
>


> Probably someone who's particularly bothered by this should submit a patch.
>

There's been a patch that's been ignored in the bug tracker for ages to at
least minimise this problem on Windows by treating EACCESS the same as
EPERM to handle the case of removable disks.

Regards

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

Re: [openssl-users] Problems verifying OCSP signatures

[Richard Moore]

On 3 January 2015 at 21:45, Walter H.  wrote:

>  On 03.01.2015 18:16, Richard Moore wrote:
>
> I've now got this working, though to do so I seem to have to take the
> certificates supplied in the OCSP response directly out of the certs field
> of the OCSP_BASICRESP and add these as intermediates for the verification
> too. It feels bad to directly access the internals of this struct but there
> doesn't seem to be another way (unless someone can enlighten me).
>
>  Cheers
>
>  Rich.
>
> the certificate you want to test its validity with OCSP has the same
> intermediate CA cert. as the OCSP responder certificate you use in OCSP
> response
>

Simply specifying the intermediates from the certificate chain of the
server doesn't appear to actually work - that's what I tried first. Sadly
I've not seen any documentation or examples of how to use this part of
openssl.

Cheers

Rich.
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: [openssl-users] Problems verifying OCSP signatures

[Richard Moore]

I've now got this working, though to do so I seem to have to take the
certificates supplied in the OCSP response directly out of the certs field
of the OCSP_BASICRESP and add these as intermediates for the verification
too. It feels bad to directly access the internals of this struct but there
doesn't seem to be another way (unless someone can enlighten me).

Cheers

Rich.

On 28 December 2014 at 16:42, Richard Moore  wrote:

> Hi All,
>
> I'm trying to get some code to verify the signature of an OCSP response to
> work properly and I'm hitting quite a few road blocks. I've also been
> talking
> to the curl developers who are having the same problems and I wondered if
> anyone can help us.
>
> I've tried 3 different ways of handling the verification and none of them
> seem
> to work reliably. All 3 work properly for checking the OCSP status of
> www.google.com, but they all fail when testing revoked.grc.com and
> tn123.org.
> I'm sure I must be doing something wrong, but I've no idea what and there
> seems to be very little documentation in this area. I've put the 3
> approaches
> I've tried below in case anyone has any ideas. Note that the reason all the
> openssl symbols has a q_XXX prefix is just due to a dlopen shim and doesn't
> change the behaviour of the functions at all.
>
> If anyone has any suggestions of what I'm doing wrong then please let me
> know.
>
> Thanks
>
> Rich.
>
> /**
>  * This version takes the whole issuer chain, and adds them as
> intermediates.
>  * It also sets up the CA store.
>  */
> bool QSslOcspReply::hasValidSignature1(const QList
> &issuers) const
> {
> // Create the certificate store
> X509_STORE *certStore = q_X509_STORE_new();
> if (!certStore) {
> qWarning() << "Unable to create certificate store";
> return false;
> }
>
> // Build a stack to put the issuer in
> STACK_OF(X509) *intermediates = 0;
> intermediates = (STACK_OF(X509) *) q_sk_new_null();
>
> if (!intermediates) {
> q_X509_STORE_free(certStore);
> return false;
> }
>
> #if OPENSSL_VERSION_NUMBER >= 0x1000L
> foreach (const QSslCertificate &cert, issuers)
> q_sk_push( (_STACK *)intermediates, reinterpret_cast *>(cert.handle()));
> #else
> foreach (const QSslCertificate &cert, issuers)
> q_sk_push( (STACK *)intermediates, reinterpret_cast *>(cert.handle()));
> #endif
>
> foreach (const QSslCertificate &caCertificate,
> QSslSocket::defaultCaCertificates())
> q_X509_STORE_add_cert(certStore, (X509 *)caCertificate.handle());
>
> int verifyResult = q_OCSP_basic_verify(d->basicresp, intermediates,
> certStore, OCSP_TRUSTOTHER);
>
> // A verify result is a failure if it is 0 or less
> if (verifyResult <= 0) {
> unsigned long errnum = q_ERR_get_error();
> const char *error = q_ERR_error_string(errnum, 0);
>
> qDebug() << "OCSP response verification failed" << verifyResult;
> qDebug() << "Error was: " << error;
> // ### TODO: Fix mem leak
> return false;
> }
> qDebug() << "OCSP response verification good";
>
> #if OPENSSL_VERSION_NUMBER >= 0x1000L
> q_sk_free( (_STACK *) intermediates);
> #else
> q_sk_free( (STACK *) intermediates);
> #endif
> q_X509_STORE_free(certStore);
>
> return true;
> }
>
> /**
>  * This version takes the whole issuer chain, and adds them as
> intermediates.
>  * It does not set up any CAs.
>  */
> bool QSslOcspReply::hasValidSignature2(const QList
> &issuers) const
> {
> // Create the certificate store
> X509_STORE *certStore = q_X509_STORE_new();
> if (!certStore) {
> qWarning() << "Unable to create certificate store";
> return false;
> }
>
> // Build a stack to put the issuer in
> STACK_OF(X509) *intermediates = 0;
> intermediates = (STACK_OF(X509) *) q_sk_new_null();
>
> if (!intermediates) {
> q_X509_STORE_free(certStore);
> return false;
> }
>
> #if OPENSSL_VERSION_NUMBER >= 0x1000L
> foreach (const QSslCertificate &cert, issuers)
> q_sk_push( (_STACK *)intermediates, reinterpret_cast *>(cert.handle()));
> #else
> foreach (const QSslCertificate &cert, issuers)
> q_sk_push( (STACK *)intermediates, reinterpret_cast *>(cert.handle()));
> #endif
>
> int verifyResult = q_OCSP_basic_verify(d->basicresp, intermediates,
> certStore, OC

[openssl-users] Problems verifying OCSP signatures

[Richard Moore]

Hi All,

I'm trying to get some code to verify the signature of an OCSP response to
work properly and I'm hitting quite a few road blocks. I've also been
talking
to the curl developers who are having the same problems and I wondered if
anyone can help us.

I've tried 3 different ways of handling the verification and none of them
seem
to work reliably. All 3 work properly for checking the OCSP status of
www.google.com, but they all fail when testing revoked.grc.com and tn123.org
.
I'm sure I must be doing something wrong, but I've no idea what and there
seems to be very little documentation in this area. I've put the 3
approaches
I've tried below in case anyone has any ideas. Note that the reason all the
openssl symbols has a q_XXX prefix is just due to a dlopen shim and doesn't
change the behaviour of the functions at all.

If anyone has any suggestions of what I'm doing wrong then please let me
know.

Thanks

Rich.

/**
 * This version takes the whole issuer chain, and adds them as
intermediates.
 * It also sets up the CA store.
 */
bool QSslOcspReply::hasValidSignature1(const QList
&issuers) const
{
// Create the certificate store
X509_STORE *certStore = q_X509_STORE_new();
if (!certStore) {
qWarning() << "Unable to create certificate store";
return false;
}

// Build a stack to put the issuer in
STACK_OF(X509) *intermediates = 0;
intermediates = (STACK_OF(X509) *) q_sk_new_null();

if (!intermediates) {
q_X509_STORE_free(certStore);
return false;
}

#if OPENSSL_VERSION_NUMBER >= 0x1000L
foreach (const QSslCertificate &cert, issuers)
q_sk_push( (_STACK *)intermediates, reinterpret_cast(cert.handle()));
#else
foreach (const QSslCertificate &cert, issuers)
q_sk_push( (STACK *)intermediates, reinterpret_cast(cert.handle()));
#endif

foreach (const QSslCertificate &caCertificate,
QSslSocket::defaultCaCertificates())
q_X509_STORE_add_cert(certStore, (X509 *)caCertificate.handle());

int verifyResult = q_OCSP_basic_verify(d->basicresp, intermediates,
certStore, OCSP_TRUSTOTHER);

// A verify result is a failure if it is 0 or less
if (verifyResult <= 0) {
unsigned long errnum = q_ERR_get_error();
const char *error = q_ERR_error_string(errnum, 0);

qDebug() << "OCSP response verification failed" << verifyResult;
qDebug() << "Error was: " << error;
// ### TODO: Fix mem leak
return false;
}
qDebug() << "OCSP response verification good";

#if OPENSSL_VERSION_NUMBER >= 0x1000L
q_sk_free( (_STACK *) intermediates);
#else
q_sk_free( (STACK *) intermediates);
#endif
q_X509_STORE_free(certStore);

return true;
}

/**
 * This version takes the whole issuer chain, and adds them as
intermediates.
 * It does not set up any CAs.
 */
bool QSslOcspReply::hasValidSignature2(const QList
&issuers) const
{
// Create the certificate store
X509_STORE *certStore = q_X509_STORE_new();
if (!certStore) {
qWarning() << "Unable to create certificate store";
return false;
}

// Build a stack to put the issuer in
STACK_OF(X509) *intermediates = 0;
intermediates = (STACK_OF(X509) *) q_sk_new_null();

if (!intermediates) {
q_X509_STORE_free(certStore);
return false;
}

#if OPENSSL_VERSION_NUMBER >= 0x1000L
foreach (const QSslCertificate &cert, issuers)
q_sk_push( (_STACK *)intermediates, reinterpret_cast(cert.handle()));
#else
foreach (const QSslCertificate &cert, issuers)
q_sk_push( (STACK *)intermediates, reinterpret_cast(cert.handle()));
#endif

int verifyResult = q_OCSP_basic_verify(d->basicresp, intermediates,
certStore, OCSP_TRUSTOTHER);

// A verify result is a failure if it is 0 or less
if (verifyResult <= 0) {
unsigned long errnum = q_ERR_get_error();
const char *error = q_ERR_error_string(errnum, 0);

qDebug() << "OCSP response verification failed" << verifyResult;
qDebug() << "Error was: " << error;
// ### TODO: Fix mem leak
return false;
}
qDebug() << "OCSP response verification good";

#if OPENSSL_VERSION_NUMBER >= 0x1000L
q_sk_free( (_STACK *) intermediates);
#else
q_sk_free( (STACK *) intermediates);
#endif
q_X509_STORE_free(certStore);

return true;
}

/**
 * This version takes the just the actual issuer, and adds it as an
intermediate.
 * It does not set up any CAs.
 */
bool QSslOcspReply::hasValidSignature3(const QSslCertificate &issuer) const
{
// Create the certificate store
X509_STORE *certStore = q_X509_STORE_new();
if (!certStore) {
qWarning() << "Unable to create certificate store";
return false;
}

// Build a stack to put the issuer in
STACK_OF(X509) *intermediates = 0;
intermediates = (STACK_OF(X509) *) q_sk_new_null();

if (!intermediates) {
q_X509_STORE_free(certStore);
return fa

Re: [openssl-users] OpenSSL Release Strategy and Blog

[Richard Moore]

What I'd find useful would be a branch for me to test with so that I can
let you know areas where we're having to get into the guts of an openssl
structure right now that will be opaque in future. IIRC last time I tried
using the define to minimise the exposed api (I forget what it was called)
there were some parts of the Qt code that could not be implemented.

Note that I think the goal of minimising the exposed api rather than having
people using the implementation details is a good thing long term, despite
the fact I'm sure it'll cause me short term pain maintaining code using
openssl.

Cheers

Rich.


On 24 December 2014 at 21:55, Dr. Stephen Henson  wrote:

> On Wed, Dec 24, 2014, Ken Goldman wrote:
>
> > >Version 1.1.0 will (moderately) break source compatibility (for example
> we will make most structures opaque etc).
> >
> > I as a user, I have two points of concern"
> >
> > 1 - Will the RSA structure be opaque?  I have a continuing need to
> > construct an RSA structure from binary arrays of public and private
> > key parts and vice versa.
> >
> > Will I lose that?
> >
>
> RSA is something which most probably will be opaque along with DSA, DH and
> the associated methods.
>
> So you wont be able to access the structure directly. However I think it is
> pretty certain there will be new utility functions to access the public and
> private key components of RSA (and DSA, DH) structures.
>
> The reason I say that is that you need that functionality to make ENGINE
> work.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> ___
> openssl-users mailing list
> openssl-users@openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: [openssl-users] Why can not get certificate chain if certificate expire

[Richard Moore]

On 18 December 2014 at 02:08, Jerry OELoo  wrote:
>
> Hi Rich:
> But why browser Chrome can show all certificate path? How did it do?
> Thanks!
>
>
Browsers fix up mistakes like this in various ways - Firefox caches
intermediates and attempts to fix things by using them if the chain is
missing. IE tries fetching them from windows update (indeed it does this
for rarely used root certificates too), it is also possible to fetch the
intermediates by downloading them from the location indicated in the AIA
extension if present in the leaf certificate. I'm not quite sure which
mechanism (or combination of mechanisms) is being used in the current
version of Chrome but it's like a variant on one of these,

Cheers

Rich.
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: [openssl-users] Why can not get certificate chain if certificate expire

[Richard Moore]

On 17 December 2014 at 08:08, Jerry OELoo  wrote:
>
> Hi All:
> I am using openssl api to get website's certificate chain. Now, For
> normal website, it works fine.
> Now I encounter a website which certificate is expire,
> https://soknad.sparebank1.no
>
>
The server is misconfigured and is only transmitting the leaf certificate -
it's missing the intermediates. So you're getting all the certificates it's
sending - one.

Rich.
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: [openssl-users] Error: A call to SSPI failed ...

[Richard Moore]

On 11 December 2014 at 10:20, Thirumal, Karthikeyan  wrote:

>  Dear team,
>
> Can someone tell me why the error is happening as SSPI failed ? Am seeing
> this new today and when I searched the internet - it says whenever there is
> a BAD formed request or when there is no client certificate - we may get
> this error. Can someone shed more light here ?
>
>
>
> 12/11/2014  12:50:06.161
>
> ByteCount: 69
>
> SSL Authentication failed A call to SSPI failed, see inner exception.
>
>
>
>
>
Since this is an error from .net you're asking the wrong place. This list
is for users of openssl.

Regards

Rich.
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: constant_time_test.c fails to compile on SuSE Enterprise Server 10 32-bit

[Richard Moore]

On 25 October 2014 00:57, Andy Schmidt 
wrote:

> Finally, the link you supplied requires a login. Are logins available
> to the general public? ... But anyway I was not able to read the
> information in that link, so I apologize for any obvious RTFM user
> errors.
>

Username: guest
Password: guest

Cheers

Rich.

Re: Can SSL_v23_method be renamed or have additional name assigned?

[Richard Moore]

On 24 October 2014 09:16, Matt Caswell  wrote:

> I agree. This topic came up briefly at our recent OpenSSL team meeting
> in Dusseldorf. I think there was a strong consensus within the team to
> create a new name (probably with SSLv23_method #defined to point to
> the new name). The name TLS_method has been proposed. This would be
>

Doing this using a #define would break binary compatibility. Wouldn't it be
better to just have SSLv23_method remain a function that just calls the new
one?

Cheers

Rich.

Re: On 2K keys and SHA-256

[Richard Moore]

No objection at all. Perhaps it might be worth checking that the other
defaults are sane too at the same time though. e.g. x509 versions etc.

Rich.


On 8 September 2014 22:59, Salz, Rich  wrote:

> We are considering changing the default keysize (RSA, DSA, DH) from 1K to
> 2K, and changing the default signing digest from SHA-1 to SHA-256.
>
>
>
> We've already committed this to HEAD/master.  We would like to make this
> change in the upcoming 1.0.2 release as well. Several downstream
> distributions, such as Debian, have already done this. Microsoft has
> already announced deprecation of SHA-1  certificates, and Google just
> recently posted a fairly aggressive plan for Chrome.
>
>
>
> Does anyone have strong objections?
>
>
>
> --
>
> Principal Security Engineer
>
> Akamai Technologies, Cambridge MA
>
> IM: rs...@jabber.me Twitter: RichSalz
>
>
>

Re: Openssl crashed when loading certificates

[Richard Moore]

On 20 May 2014 20:13, David Li  wrote:

> So obviously my SSL_CTX object wasn't created properly. Now I have to
> figure out what it means by "library has no ciphers".
>
>
You haven't called the functions to initialise openssl.

Rich.