Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Viktor Dukhovni]

> On Jan 25, 2018, at 5:11 AM, Richard Levitte  wrote:
> 
> This is confusing, and not what was intended.  In other words,
> openssl-project is *not* a new openssl-dev!  If it was, I don't see
> why we would even bother making a new list...

It is moderated, and won't have misplaced user questions.  Technical
topics related to the future evolution of OpenSSL should I think be
open for discussion on this list if they're not yet sufficiently
well formulated for tracking as a GitHub issue.  These might be design
ideas, clarification of requirements, ...  The point being that mailing
lists are good for *discussion* and Github is not particularly well
suited for that.

-- 
Viktor.

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Viktor Dukhovni]

> On Jan 24, 2018, at 1:25 PM, Dr. Matthias St. Pierre 
>  wrote:
> 
> Ok, I didn't know that. If anyone seriously participating on GitHub can
> join the moderated openssl-project list then this sounds like a good
> replacement for openssl-dev, because that list will be more focused
> and not bothered with so many misplaced posts that should have
> gone to openssl-users.

Interested participants can sign up at:

  https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Viktor.

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Viktor Dukhovni]

> On Jan 24, 2018, at 12:55 PM, Dr. Matthias St. Pierre 
>  wrote:
> 
> As for the two mailing lists openssl-users and openssl-dev: It was always
> my understanding that the former was for usability questions starting
> from newbie questions up to very sophisticated subjects, whereas
> openssl-dev was for discussion around the development process itself.

Where "development process" means development of OpenSSL itself, not
software dependent on OpenSSL.  Since openssl is primarily a developer
toolkit, not end-user software, the openssl-users list is really for
developers, just not developers of OpenSSL itself.

> If we agree that mailing lists are preferrable to GitHub threads, then we
> should not close down openssl-dev.

Well, but we now have "openssl-project" for discussions of the
ongoing development of OpenSSL.  It is mostly for team members,
but though it is moderated, IIRC others can join and post.

> Because openssl-project is readonly for most developers

s/developers/users/

> and I don't think it would be a good idea to join openssl-dev
> and openssl-users.

Well, I've been on both for a long time, and mostly find that
I wish the openssl-dev posts were on openssl-users instead,
they really mostly aren't about ongoing OpenSSL development.

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Viktor Dukhovni]

> On Jan 24, 2018, at 9:27 AM, Michael Richardson  wrote:
> 
>> email clients are designed to handle hundreds to thousands of messages
>> a day, Github UI isn't

Indeed email is best for informal ad-hoc back and forth threaded
discussion, while Github et. al. are for issue tracking.

If there's a clear problem that requires tracking and resolution,
then the right forum is Github.  If there's a topic to discuss,
we have openssl-users.  Most openssl-dev threads were more
appropriate for openssl-users.

So I'm not convinced we need two free-form discussion lists, but
concur that if it is discussion one wants, then email clearly
superior to Github issue tracking.  The key question is whether
openssl-users suffices to meet that need.

-- 
Viktor.

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

Re: [openssl-dev] Is X509_free(NULL) ok?

[Viktor Dukhovni]

> On Dec 20, 2017, at 5:50 PM, Ray Satiro via openssl-dev 
>  wrote:
> 
> 'm trying to figure out whether it's supported to call X509_free(NULL)
> in 1.0.2 and beyond. It's not documented what action occurs when the
> pointer is null. Also generally speaking is it supported to call openssl
> free functions with null pointers?


All ASN.1 objects (such as X509 *) that are implemented via
IMPLEMENT_ASN1_FUNCTIONS(typename) are freed by ASN1_item_free(),
which I believe handles NULL inputs.

If you don't see immediate crashes on trying it, you can use it
on NULL inputs with confidence that this is intentional and not
going to change.

-- 
-- 
Viktor.

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

Re: [openssl-dev] Certificate Limitation Profile

[Viktor Dukhovni]

On Tue, Nov 28, 2017 at 11:37:35PM +0300, Dmitry Belyavsky wrote:

> Thank you. It seems reasonable to add nextUpdate field to
> the header of CLP to avoid problems related to using stale CLP.
> 
> I expect that fresh CLPs in most cases are delivered via update procedures
> of applications, and update mechanism allows fresh enough CLP.
> 
> On the other hand enforcing freshness can cause difficulties in situation
> when an application becomes unsupported on a specific version of platform
> (e.g. stale version of Android/iOS).

Perhaps a sensible way to handle nextUpdate is to refuse to import
a purportedly fresh CLP whose nextUpdate has expired or is older
than what you have.  If an application is failing to get updates,
then it can continue to run with what it has.

The idea is to prevent "rollback" attacks, more than fail closed
on expired CLPs when nothing fresh is available.

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

Re: [openssl-dev] Certificate Limitation Profile

[Viktor Dukhovni]

On Tue, Nov 28, 2017 at 07:18:48PM +, Blumenthal, Uri - 0553 - MITLL wrote:

> I think it makes perfect sense to sign CLP, because it allows you to
> separate trust in the server you�re downloading the content from and the
> content itself.

The problem with "data at rest" signatures is that it then becomes
difficult to ascertain freshness.  How do you know that you're not
usign a much too stale version of the CLP, that fails to include a
recently deprecated trust anchor.

Therefore, one needs to be careful to not rely *solely* on the
signature of the CLP payload.  It is still important to get a fresh
copy from a trusted source sufficiently often.

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

Re: [openssl-dev] Contributing to TLS 1.3 - Where to start?

[Viktor Dukhovni]

> On Apr 4, 2017, at 3:28 PM, Thiago Arrais  wrote:
> 
> Viktor,
> 
> This is related to this message on openssl-users, right?
> 
> https://www.mail-archive.com/openssl-users@openssl.org/msg81251.html

Yes.

> As I understand this isn't directly related to TLS 1.3. But it can work
> as an intro to the codebase.

Yes, and we want all contributions to be documented, so the documentation
is a good place to start.  Perhaps then tests, and only after that new code.

-- 
Viktor.

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

Re: [openssl-dev] Contributing to TLS 1.3 - Where to start?

[Viktor Dukhovni]

> On Apr 4, 2017, at 1:09 PM, Matt Caswell  wrote:
> 
> Actually I have a suggestion for a fairly small self-contained piece of
> work suitable for a starting project.

My suggestion would be start with something simpler still, and get used
to the format of the documentation, which will be required for future
more ambitious work.

Specifically, update the documentation of SSL_CTX_set_verify_depth(3)
to correctly describe the semantics of the "verify depth" in OpenSSL
1.1.0 and later.  The documentation was updated in the CLI verify(1)
manpage, but some of the required changes did make it into the API
document.

-- 
Viktor.

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

Re: [openssl-dev] verify depth behavior change from 1.0.2 to 1.1.0?

[Viktor Dukhovni]

> On Apr 3, 2017, at 4:26 PM, Benjamin Kaduk  wrote:
> 
> There was a fair amount of churn in x509_vfy.c with the inclusion
> of the DANE stuff and whatnot, so it's not immediately clear to me
> when this change actually happened.  I think there are good
> arguments for the current 1.1.0 behavior and it doesn't really make
> sense to try to change back to the historical behavior, but it would
> be good to know when the change actually happened and that it is/was
> a known change.  Ideally we could also document the different
> behavior between 1.0.x and 1.1.0 better; any thoughts about where to
> do so?

https://www.openssl.org/docs/man1.1.0/apps/verify.html

   -verify_depth num

Limit the certificate chain to num intermediate CA certificates.
A maximal depth chain can have up to num+2 certificates, since
neither the end-entity certificate nor the trust-anchor
certificate count against the -verify_depth limit.

https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_verify_depth.html

SSL_CTX_set_verify_depth() sets the maximum depth for the
certificate chain verification that shall be allowed for ctx.
(See the BUGS section.)
...
BUGS

The certificate verification depth set with SSL[_CTX]_verify_depth()
stops the verification at a certain depth. The error message
produced will be that of an incomplete certificate chain and
not X509_V_ERR_CERT_CHAIN_TOO_LONG as may be expected.

The 1.0.2 behaviour was under-documented and somewhat broken.  This
was fixed in 1.1.0.


Unfortunately, the SSL_CTX_set_verify_depth(3) was not brought up to date,
contributes welcome:

   https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_verify_depth.html

-- 
Viktor.

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

Re: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux)

[Viktor Dukhovni]

> On Mar 1, 2017, at 11:46 AM, Steffen Nurpmeso  wrote:
> 
> No, not that i know.  But this -- thanks -- lead me to the
> following, which is the KISS that you want?
> Ciao!
> 
> diff --git a/apps/apps.c b/apps/apps.c
> index 216bc797d..3afbbaef2 100644
> --- a/apps/apps.c
> +++ b/apps/apps.c
> @@ -1221,7 +1221,8 @@ X509_STORE *setup_verify(const char *CAfile, const char 
> *CApath, int noCAfile, i
> if (lookup == NULL)
> goto end;
> if (CApath) {
> -if (!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM)) {
> +if (!app_isdir(CApath) ||
> +!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM)) 
> {
> BIO_printf(bio_err, "Error loading directory %s\n", CApath);
> goto end;
> }

We may need to be careful.  With OpenSSL <= 1.0.2, one way to suppress the
built-in default CApath was to set "-CApath" to a non-existent directory.
Users may have scripts relying on this behaviour.  Now with 1.1.0 on some
platforms OpenSSL already rejects non-existent directories, and we also
provide a "-no-CAfile" option, but this change will extend the change to
what is likely our most popular platform.

So it will at least deserve a comment in the "NEWS"/"CHANGES" files.  

-- 
Viktor.

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

Re: [openssl-dev] SNI by default in s_client

[Viktor Dukhovni]

> On Feb 13, 2017, at 12:32 PM, Viktor Dukhovni <openssl-us...@dukhovni.org> 
> wrote:
> 
> That said, I don't think that enabling SNI by default *in s_client* is
> sufficient cause to motivate such a feature.  The s_client command adds
> new options from time to time, and IIRC we've never before back-ported
> these as NOPs.  If an "ignore_unknown" option is warranted, it is for
> all the other new things we might add in addition to "-noservername".

One more thing I should note.  The implementation should not break the
"-dane_tldsa_domain" option.  That is, with no explicit "-servername"
and with "-dane_tlsa_domain", the SNI name must come from that option,
and not the "-connect" hostname.

-- 
Viktor.

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

Re: [openssl-dev] SNI by default in s_client

[Viktor Dukhovni]

> On Feb 13, 2017, at 12:35 PM, Salz, Rich  wrote:
> 
> I think it should be called out in the docs and CHANGES however.

Yes, definitely.

-- 
Viktor.

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

Re: [openssl-dev] SNI by default in s_client

[Viktor Dukhovni]

> On Feb 13, 2017, at 11:13 AM, Matt Caswell  wrote:
> 
> I'd like to canvas opinion on this PR:
> https://github.com/openssl/openssl/pull/2614
> 
> At the moment s_client does not add the SNI extension by default. You
> have to explicitly ask for it using the "-servername" option.

So long as the "-servername" option remains in place and supports
setting the SNI name to something other than the host part of the
"-connect" option I think we provide sufficient compatibility with
the legacy s_client CLI interface.  Adding a "-noservername" option
is compatible enough.

The change of default behaviour is not an interface change, it is a
behaviour change, and could even, with enough squinting, be viewed
as a bugfix, given the modern TLS landscape.

That said, even behaviour changes in stable releases do merit
discussion.  Certainly I would not support the proposed change in
a patch release.  For 1.1.1, I am not opposed, because s_client
is not stunnel, it is primarily useful as a diagnostic tool, and
while some monitoring tools built around it may behave differently
as a result of the change, it is not clear that delaying to 1.2.x
helps.  If we're going to do this, I think that 1.1.1 is OK, if the
interface remains compatible.

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

Re: [openssl-dev] about enc 'magic' data and salt handling

[Viktor Dukhovni]

> On Jan 13, 2017, at 7:50 PM, Tom Francis  wrote:
> 
> 
> The enc command is really just an example, IMO. If you want something that's 
> useful for production purposes (and even follows standards!), I recommend 
> looking at the cms command. It'll encrypt, decrypt, sign (and verify 
> signatures) data in a standards-based format. It's not the easiest thing to 
> use, but it's better to focus on something like that, rather than a 
> proprietary format that was never really intended for real data exchange.

While CMS is indeed often the more appropriate tool, it has a drawback
for streaming data.  Only the write side can stream.  CMS readers must
hold the entire decrypted object in memory.  For this reason, I've
sometimes used enc(1) with the symmetric random encryption key protected
to a public key, and a separate signed MAC computed over the whole stream.

Otherwise, indeed enc(1) is often more useful for raw symmetric operations
when doing troubleshoots.

-- 
Viktor.

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

Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

[Viktor Dukhovni]

On Mon, Jan 09, 2017 at 07:57:43PM +0100, Leonard den Ottolander wrote:

> Considering that AES-192 seems to be very resistant against related key
> attacks (http://eprint.iacr.org/2009/317) and the algorithm is already
> available in the openssl code I am trying to expose the AES-192
> ciphers. 

There are no AES-192 ciphersuites in the IANA TLS registry:


http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

so these cannot (interoperably) be used with TLS.

> +/* AES-192 */
> +/* Cipher A8 */
> +{
> + 0, /* not implemented (non-ephemeral DH) */
> + TLS1_TXT_DH_DSS_WITH_AES_192_SHA256,
> + TLS1_CK_DH_DSS_WITH_AES_192_SHA256,

That codepoint is: TLS_PSK_WITH_AES_128_GCM_SHA256

> +/* Cipher A9 */
> +{
> + 0, /* not implemented (non-ephemeral DH) */
> + TLS1_TXT_DH_RSA_WITH_AES_192_SHA256,
> + TLS1_CK_DH_RSA_WITH_AES_192_SHA256,

That codepoint is: TLS_PSK_WITH_AES_256_GCM_SHA384

> +/* Cipher AA */
> +{
> + 1,
> + TLS1_TXT_DHE_DSS_WITH_AES_192_SHA256,
> + TLS1_CK_DHE_DSS_WITH_AES_192_SHA256,

Another conflict.

> +/* Cipher AB */
> +{
> + 1,
> + TLS1_TXT_DHE_RSA_WITH_AES_192_SHA256,
> + TLS1_CK_DHE_RSA_WITH_AES_192_SHA256,

Another conflict...

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

Re: [openssl-dev] Linker error when adding new cipher in crypto folder

[Viktor Dukhovni]

> On Dec 29, 2016, at 9:36 PM, Schmicker, Robert  
> wrote:
> 
> However, as soon as I make a call to my cipher in test.c I get a linker error 
> and gcc is unable to find any of my functions.

Edit util/libcrypto.num and/or util/libssl.num, only the symbols listed there
are exported by the library shared objects.

-- 
Viktor.

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

Re: [openssl-dev] Cross compiling openssl for an old ARM environment - howto?

[Viktor Dukhovni]

> On Dec 19, 2016, at 2:07 PM, Salz, Rich  wrote:
> 
>> Are we saying that it absolutely will not support ARM7 thumb mode anymore?
> 
> Nobody is saying that.  We're saying that if the address-space is 16bit, 
> openssl will not work.
> 
>> Wouldn't the generic C-only version (no ASM) support pretty much any 
>> platform?
> 
> Probably.

For ARM platforms, especially on resource-constrainted variants, the OP is
most likelyh better of with mbedTLS:

https://tls.mbed.org/

-- 
Viktor.

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

Re: [openssl-dev] cert_cb and TLS tickets

[Viktor Dukhovni]

On Fri, Dec 09, 2016 at 09:47:19PM +0100, Fedor Indutny wrote:

> > The callback is *correctly* only called when choosing the server
> > certificate.  In *that* case, it is always called.  When sessions
> > are resumed, there is no certificate to present, so no callback is
> > made.
> 
> That's why I said that the intended logic is clear. However, this
> implementation makes the API unusable in at least one case. Even more,
> there are no alternatives to this API, meaning that there is no other way
> to delay certificate/key/context selection. Clearly this is the case for
> which the API was created.

Resumed sessions don't select any certificates, so it makes no
sense to invoke certificate selection callbacks.

> Ticket rotation is already possible in both bud and node.js and is
> completely unrelated to this issue. Even with ticket rotation valid tickets
> will cause asynchronous SNI lookups to be skipped.

If you deny the key id, then a new session will be negotiated, and
certificate selection callbacks will be invoked.

> However, when valid TLS ticket is received - OpenSSL will skip the
> `cert_cb` and will just do regular handshake as no `cert_cb` was set. This
> breaks balancing and OCSP stapling fetching, which are major use cases for
> both bud and node.js (which can do all of this too through external
> modules).

There is no OCSP with resumed sessions, no certificates are sent
by the server or checked by the client.  If you want certificates,
don't do session resumption.

OpenSSL is behaving correctly.  This is a fundamental feature of TLS.

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

Re: [openssl-dev] cert_cb and TLS tickets

[Viktor Dukhovni]

On Fri, Dec 09, 2016 at 08:43:01PM +0100, Fedor Indutny wrote:

> During development of one feature for my TLS proxy bud, I have discovered
> that the cert_cb is invoked only for newly generated tickets/sessions. The
> reasoning behind this is clear, but I believe that it is most likely needs
> a revision. Here is my reasoning:

The callback is *correctly* only called when choosing the server
certificate.  In *that* case, it is always called.  When sessions
are resumed, there is no certificate to present, so no callback is
made.

> Furthermore, with the TLS ticket provided
> application can no longer chose to provide a different certificate in case
> of expiration or revocation.

You can implement a ticket key callback that when appropriate, will
decline tickets under suitable conditions, in which case a full
handshake will be performed.

Custom ticket callbacks that do session ticket key rotation are a
good idea in any case, the default tickets are not rotated, which
is not apppropriate for long-running processes.

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

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

[Viktor Dukhovni]

On Wed, Oct 05, 2016 at 07:05:06AM +, Sergey G Brazhnikov via RT wrote:

> Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be
> decrypted with previous releases and vice versa.
> Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and
> 0.9.8(cast5-cfb only)
> 
> All built without errors, passed all tests.
> Configuration VC-WIN32, os Windows 8.1 Pro x64, compiler vs2015.

Especially on Windows systems you have to be mindful of the
character-set encoding of the passphrase.

Try setting OPENSSL_WIN32_UTF8=1 in your environment and see if
that helps.  For interoperable password-based encryption the password
character-set needs to be standard.

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

Re: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0

[Viktor Dukhovni]

On Sat, Sep 17, 2016 at 03:46:53PM +, Salz, Rich wrote:

> > If a client offers ECDHE ciphers with no curve list, one might 
> > alternatively just
> > use P-256.  It is likely better than the other choices.  Most clients will 
> > send a
> > curve list.
> 
> Most will, and I'd rather get people off P256 and onto X25519, which is
> why I prefer no ECDHE unless the client sends a  curve list.

I think our responsibility to our users is primarily to provide
the best security we're able, and only secondarily to prod and
nudge them in the direction of progress.

Offering X25519 and making it preferred over P-256 is compatible
with those priorities.  Avoiding ECDHE, and using FFDHE or RSA key
exchange (recall that Chrome, e.g., avoids FFDHE) is not IMHO in
the interest of the users, and so is not I think in ours.

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

Re: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0

[Viktor Dukhovni]

On Sat, Sep 17, 2016 at 02:35:20PM +, Salz, Rich wrote:

> > When we added X25519 to BoringSSL, we at the same time started made the
> > server require clients supply a curve list (and otherwise we'd just pick
> > a non-ECDHE cipher), because of this issue. That went in back in December
> > 2015 and it's been running just fine. I'd recommend OpenSSL do the same.
> 
> In other words:  only use ECDHE if client specifies a curve list.  WFM.

If a client offers ECDHE ciphers with no curve list, one might
alternatively just use P-256.  It is likely better than the other
choices.  Most clients will send a curve list.

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

Re: [openssl-dev] [openssl.org #4673] a weird error, please help to check whether is it a but. thanks!

[Viktor Dukhovni]

> On Sep 12, 2016, at 4:08 PM, zy_chongqing via RT  wrote:
> 
> SSL_CTX_use_certificate_file return 0, and the log show: error:140AB18F:SSL 
> routines:SSL_CTX_use_certificate:ee key too small
> 1. this programe is running well in one server, but failed in another. 
> actually these 2 servers is mirrow relationship. 2. I checked the pem file 
> (as attached), also is same on two servers3. I checked the error reason, but 
> cannot find any description about it in the website.I am almost crazy for 
> this issue, would you help to check what's the reason of this error for me? 
> thanks a lot!
> my OS: Linux version 3.7.10-1.1-desktop (geeko@buildhost) (gcc version 4.7.2 
> 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #1 SMP PREEMPT Thu 
> Feb 28 15:06:29 UTC 2013 (82d3f21)OpenSSL version: OpenSSL 1.1.0  25 Aug 2016
> thanks & Regards!

Use stronger keys, see:

https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_security_level.html

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #4658] bug: Abort() in 1.0.2h parsing server cert in ASN.1 routine

[Viktor Dukhovni]

On Thu, Sep 01, 2016 at 01:58:00PM -0700, Quanah Gibson-Mount wrote:

> >The issue only happens when proxying IMAP on port 143 with startTLS or
> >993 (IMAPS).  It does not occur on POP w/ starttls or web traffic (443).
> >It also is only happening with this one particular client, as we have
> >numerous customers (and our own setup) not experiencing this issue.
> >
> >I'll have them supply what's in their keystore that Jetty's using as well.
> 
> Note, when this happens, the nginx log shows:
> 
> 2016/08/22 03:12:10 [info] 530#0: *3326370 SSL_do_handshake() failed (SSL:
> error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate
> unknown:SSL alert number 46) w
> *** Error in `nginx: worker process': free(): invalid size:
> 0x010cf560 ***

If this is the outbound connection from nginx to the backend IMAP
server, then the "alert" is received by nginx from the IMAP server,
which means that it is the IMAP server that fails to authenticate
the client cert used by nginx.

In which you're looking at the wrong certs:

> The CA certs in play are the same for both the jetty process being proxied
> to, and what nginx is using.  I see nothing unusual about the server cert on
> the jetty side.

Perhaps something goes wrong when the connection fails as a result
of the IMAP server terminating it with an alert.

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

Re: [openssl-dev] SSL_CTX_use_certificate_chain_file()

[Viktor Dukhovni]

On Fri, Aug 26, 2016 at 03:14:58PM +, asmar...@yahoo.com wrote:

> Is there any negative impact ofusing SSL_CTX_use_certificate_file() and
> SSL_CTX_use_certificate_chain_file() together?

The first is redundant and should avoided.

> My application loads thecertificate using SSL_CTX_use_certificate_file() and
> loads the complete chain using SSL_CTX_use_certificate_chain_file().

The latter also loads the leaf certificate, so the former is not needed.

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

Re: [openssl-dev] [openssl.org #4658] bug: Abort() in 1.0.2h parsing server cert in ASN.1 routine

[Viktor Dukhovni]

On Wed, Aug 24, 2016 at 11:17:21PM +, Quanah Gibson-Mount via RT wrote:

> When a process (nginx in this case) has this as the server cert, it core 
> dumps with an abort() when clients request the cert:

You say the server dumps core, and yet:

> #1  0x7f22ba125ce8 in __GI_abort () at abort.c:90
> [...]
> #14 0x7f22bac435ec in d2i_X509 (a=a@entry=0x0, 
> in=in@entry=0x7ffc53c49a60, len=len@entry=1517) at x_x509.c:143
> #15 0x7f22baf71da2 in ssl3_get_server_certificate (s=s@entry=0x2167a50) 
> at s3_clnt.c:1228
> #16 0x7f22baf76cee in ssl3_connect (s=0x2167a50) at s3_clnt.c:345
> #17 0x7f22baf8166e in ssl23_get_server_hello (s=0x2167a50) at 
> s23_clnt.c:799
> #18 ssl23_connect (s=0x2167a50) at s23_clnt.c:228

this is clearly a TLS client-side stack trace.  Why is nginx acting
as an SSL/TLS client?

> #19 0x0044a755 in ngx_ssl_handshake (c=0x7f22b8ca0f60) at 
> src/event/ngx_event_openssl.c:791
> #20 0x0044adbf in ngx_ssl_handshake_handler (ev=0x7f22b8b99640) at 
> src/event/ngx_event_openssl.c:939
> #21 0x0043a8da in ngx_event_process_posted (cycle=0x1e86db0, 
> posted=0x73d4e8 ) at src/event/ngx_event_posted.c:40
> #22 0x0043843a in ngx_process_events_and_timers (cycle=0x1e86db0) 
> at src/event/ngx_event.c:275
> #23 0x00445dad in ngx_worker_process_cycle (cycle=0x1e86db0, 
> data=0x1) at src/os/unix/ngx_process_cycle.c:879
> #24 0x004423cb in ngx_spawn_process (cycle=0x1e86db0, proc=0x445bca 
> , data=0x1, name=0x4ff02f "worker process", 
> respawn=1)
> at src/os/unix/ngx_process.c:198
> #25 0x0044579d in ngx_reap_children (cycle=0x1e86db0) at 
> src/os/unix/ngx_process_cycle.c:688
> #26 0x0043 in ngx_master_process_cycle (cycle=0x1e86db0) at 
> src/os/unix/ngx_process_cycle.c:241
> #27 0x004075fb in main (argc=3, argv=0x7ffc53c4a278) at 
> src/core/nginx.c:407

This feels like some sort concurrency/reentrancy issue, and the
certificate processed is probably one that nginx got off the wire
from a remote server.  Find out what nginx is connecting to and
why, and whether there are any potential concurrency issues.

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

Re: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain

[Viktor Dukhovni]

> On Aug 9, 2016, at 2:52 PM, Salz, Rich via RT  wrote:
> 
> As Viktor pointed out, this doesn't work in 1.0.1

The story is a bit more complicated.  What's really going on is that
root (self-signed) CAs in the trust store are backwards-compatible
implicit trust-anchors for all purposes.  Intermediate certificates
require auxiliary trust settings in the trust store to specify any
purposes for which they are trusted or rejected as trust-anchors.

Trusted certificates can be created via the "-addtrust" option of
"openssl x509".  I've not checked 1.0.1, but explicitly trusted
intermediates are likely to work with 1.0.1 if decorated as trusted via:

   openssl x509 -in cert.pem -trustout -addtrust serverAuth -out trusted.pem

or:

   openssl x509 -in cert.pem -trustout -addtrust anyExtendedKeyUsage -out 
trusted.pem

or similar.

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain

[Viktor Dukhovni]

On Tue, Aug 09, 2016 at 10:53:59AM +0100, David Woodhouse wrote:

> > As expected, unless you use the "-partial" flag in the command-line
> > utilities, or use the X509_VERIFY_PARAM_set_flags() to set the
> > X509_V_FLAG_PARTIAL_CHAIN flag when using the API.
> 
> Is there an equivalent for 1.0.1?

None that I'm aware of, partial chain support was added in 1.0.2.

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

Re: [openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain

[Viktor Dukhovni]

On Tue, Aug 09, 2016 at 01:45:24AM +, William M Edmonds via RT wrote:

> If I specify a CAfile that includes the leaf certificate and/or
> intermediate CA certificates, but not the root certificate, then
> verification fails.

As expected, unless you use the "-partial" flag in the command-line
utilities, or use the X509_VERIFY_PARAM_set_flags() to set the
X509_V_FLAG_PARTIAL_CHAIN flag when using the API.

This ticket should be closed.

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

Re: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation

[Viktor Dukhovni]

On Mon, Aug 08, 2016 at 08:57:26PM +0200, Sebastian Andrzej Siewior wrote:

> This is a computation attack and unfortunately the way a SSL handshake
> works. I understand that this `feature' is part of the TLS specification
> and I am not trying to nuke from openssl. Instead I would like to
> describe the possible attack and some countermeasures to mitigate its
> outcome. Having it in the doc section would allow one to ping other
> projects, point them to this section and ask them if they could drop the
> support for re-negotiation request from the client. From looking around,
> nginx for instance does not support renegotiation from client's side.

Postfix supports rate limiting new session creation:


http://www.postfix.org/postconf.5.html#smtpd_client_new_tls_session_rate_limit

Other servers can implement similar resource limits as appropriate.

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

Re: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Viktor Dukhovni via RT]

> On Jul 19, 2016, at 5:26 PM, Matt Caswell via RT  wrote:
> 
>> Most of all, we use CRYPTO_THREAD_run_once() internally to initiate the first
>> locks, so pretty much in an initial state of the library (not entirely true,
>> since we do these inits opportunistically, but it's probable that they happen
>> very early on). If they are having memory allocation, the running app is
>> probably in deep shit anyway, so a hard assert in our diverse inits would
>> probably be appropriate either way.
> 
> You are assuming that the application loads and inits OpenSSL early and
> that it is critical to its function. It may not be.

Postfix expects to be able to continue "degraded" operation without TLS,
when TLS initialization fails.  Asserts are not acceptable.  They would
cause Postfix to look for a different SSL library.

When initialization fails, all subsequent calls can return errors, but
assert is not an option.

-- 
Viktor.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Viktor Dukhovni]

On Mon, Jul 11, 2016 at 05:48:06PM +, Salz, Rich via RT wrote:

> Previously we've changed return-types from void to int.  If there's still 
> time, that seems like the thing to do here.

With pthread_once and friends the pattern is to use void init
functions, and as necessary check for success by examining the
resulting state after the fact.

The init function passed to pthread_once() is defined to take no
arguments and return no results.

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

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[Viktor Dukhovni]

On Fri, Jul 08, 2016 at 07:30:26PM +0100, David Woodhouse wrote:

> > I tried the naïvely obvious step of changing all instances of
> > DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.
> 
> Of course, it's because DTLS_VERSION_LT and friends are doing precisely
> the opposite of what their names imply, numerically. I hesitate to call
> this a 'fix' but it highlights the issue:

Yes, unfortunately, the DTLS "bad" version of 0x0100 looks like a
very high DTLS version.  So comparisons require a special case.
Given that DTLS1_VERSION is 0xFEFF, indeed the next "lower" version
is 0xFF00 as you suggest below:


> diff --git a/ssl/ssl_locl.h b/ssl/ssl_locl.h
> index ef5eb8c..218dcce 100644
> --- a/ssl/ssl_locl.h
> +++ b/ssl/ssl_locl.h
> @@ -259,10 +259,11 @@
>c[1]=(unsigned char)(((l)>> 8)&0xff), \
>c[2]=(unsigned char)(((l))&0xff)),c+=3)
>  
> -#define DTLS_VERSION_GT(v1, v2) ((v1) < (v2))
> -#define DTLS_VERSION_GE(v1, v2) ((v1) <= (v2))
> -#define DTLS_VERSION_LT(v1, v2) ((v1) > (v2))
> -#define DTLS_VERSION_LE(v1, v2) ((v1) >= (v2))
> +#define dtls_ver_cmp(v1) (((v1) == DTLS1_BAD_VER) ? 0xff00 : (v1))
> +#define DTLS_VERSION_GT(v1, v2) (dtls_ver_cmp(v1) < dtls_ver_cmp(v2))
> +#define DTLS_VERSION_GE(v1, v2) (dtls_ver_cmp(v1) <= dtls_ver_cmp(v2))
> +#define DTLS_VERSION_LT(v1, v2) (dtls_ver_cmp(v1) > dtls_ver_cmp(v2))
> +#define DTLS_VERSION_LE(v1, v2) (dtls_ver_cmp(v1) >= dtls_ver_cmp(v2))

Perhaps rename dtls_ver_cmp() to dtls_ver_ordinal(), "cmp" suggests
that you're actually doing a comparison.  Given this macro, one
might consider complementing the versions, so that the ordinals
compare in the usual way:

#define dtls_ver_ordinal(v) (((v) == DTLS1_BAD_VER) ? 0x00ff : (0x ^ 
(v)))

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

Re: [openssl-dev] [openssl.org #4502] CT todos

[Viktor Dukhovni via RT]

> On May 31, 2016, at 1:15 PM, Rich Salz via RT  wrote:
> 
> I do not understand what should be done for this ticket. Call me stupid :)

I took care of the requisite changes already. Feel free to close the ticket.

-- 
Viktor.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4502
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Viktor Dukhovni]

On Tue, May 31, 2016 at 02:49:05PM +, Blumenthal, Uri - 0553 - MITLL wrote:

> >Could you explain your point in more detail than putting "wrong"
> >in bold text? Though ad-hoc, it seems about the best one can do,
> >absent additional information.
> 
> IMHO allowing CN to be interpreted as a DNS name would open a new attack
> surface by making more name collisions (between people and host names)
> possible.

That genie is already out of the bottle, see RFC6125 references
upthread.  What's under discussion is extending DNS nameConstraints
to the CN, *given* that it is already often used in name checks.

Nobody is proposing using CN in name checks where it is not already
in use.

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

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Viktor Dukhovni]

> On May 31, 2016, at 9:54 AM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
>> As one example, mozilla::pkix treats the CN as a dNSName/iPAddress iif there 
>> is no subjectAltName extension and iif the CN is a valid dNSNa/iPAddress 
>> syntactically.
> 
> That approach seems wrong.

Could you explain your point in more detail than putting "wrong"
in bold text? Though ad-hoc, it seems about the best one can do,
absent additional information.

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Viktor Dukhovni]

> On May 31, 2016, at 2:43 AM, Brian Smith  wrote:
> 
> Not too long ago, there were changes to the CABForum rules about certificates 
> to make it easier for any website to get a CA certificates constrained to its 
> domain name. There were some problems with the loosening of the rules, and 
> Apple has been slow to implement name constraints, so not many websites are 
> taking advantage of them. But, soon, I am hopeful, and I expect, that it will 
> soon be as easy to get name-constrained CA certificate as it is to get a 
> wildcard certificates now. In fact, it is really important for the security 
> of many (smaller and medium-sized) websites that this become possible, 
> because this would make HPKP work much better and reduce risks relative to 
> wildcard certificates.
> 
> In particular, we should be designing things based on the assumption that in 
> the next few years, the owner of briansmith.org can get a CA certificate with 
> name constraint of dNSName=briansmith.org. Then the owner of briansmith.org 
> will be able to put Subject={CN=google.com} in his certificates if he feels 
> like it. And, we shouldn't even expect such certificates to be revoked 
> because they will be harmless to anybody that does validation correctly (i.e. 
> by either ignoring the subject CN or by applying name constraints to the 
> subject CN).

Well, if this becomes reality, it puts the final nail in the coffin of OpenSSL
versions prior to 1.0.2.  These don't have built-in name checks, and 0.9.8 and
1.0.0 are no longer supported, but are still used on some legacy systems.

For 1.0.2 and 1.1.0 it is possible to "align" the behaviour of nameConstraints
with the built-in name checks for applications that use the built-in name 
checks.

The ad-hoc --- apply nameConstraints if the CN is a valid DNS name --- approach
could perhaps be of some use with 1.0.1.  I might note that RFC 6125 says that
CN-ID is only applicable when the subject DN has exactly one CN component, but
various applications have historically chosen either the first, last or any CN
component in an ad-hoc manner.  Sot is also not clear what OpenSSL should do
when there are multiple CNs.

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

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Viktor Dukhovni]

On Tue, May 31, 2016 at 02:54:13AM +, Brian Smith via RT wrote:

> > Applications can do that now by setting the right flag, as Viktor pointed
> > out.  I think it's too late to make the default change for 1.1
> 
> The important thing is: What happens when applications use the default
> settings? If the default settings are "don't consider the subject CN for
> name constraint processing, but do consider it for name validation" then
> that's obviously wrong and dangerous.

As of OpenSSL 1.0.2, we provide built-in name check support.  When
the built-in routines are enabled, we know whether the application
has asked us to check for DNS names (and which ones).

The built-in checks do accept CN-ID as a fallback in the absence
of DNS-IDs.  The name constraint code could make use of this to
apply name constraints to the CN-ID when we'll also be doing the
hostname checks on the CN-ID.

Now, not all (likely only a minority of) applications delegate name
checks to OpenSSL.  It is more difficult to protect applications
that do their own name checks.  If the sole name in the subject DN
is a valid DNS hostname, we could apply name constraints.  If it
is instead "Joe User", that won't look like a DNS name, and we
could ignore it.  That would be a bit of a hack, but it is not
clear that we can do any better when we have no idea what name
checks if any the application intends to perform.

Name constraints in the X.509v3 PKI have not worked well, and are
rarely used.  The attack requires a issuing CA to be willing to
issue certificates beyond its constraints, that would be quite
noticeable and rather unwise.  So I think this is not a major
problem.  We should probably make a reasonable effort to address
this, but the urgency is I think low.

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

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Viktor Dukhovni via RT]

> On May 30, 2016, at 10:06 PM, Salz, Rich via RT  wrote:
> 
>> I'm not sure what "deprecated" and "mandated" mean in the openssl
>> context.  If openssl actually de-implemented CN-as-hostname and actually
>> mandated SAN, that would solve the nameConstraints bypass bug in grand
>> style.
> 
> Applications can do that now by setting the right flag, as Viktor pointed 
> out.  I think it's too late to make the default change for 1.1

Well, to be fair, I was proposing a new flag.  We don't yet have a flag to
suppress processing of CN in the absence of DNS-ID SANs.

-- 
Viktor.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3502
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Viktor Dukhovni]

> On May 30, 2016, at 10:06 PM, Salz, Rich via RT  wrote:
> 
>> I'm not sure what "deprecated" and "mandated" mean in the openssl
>> context.  If openssl actually de-implemented CN-as-hostname and actually
>> mandated SAN, that would solve the nameConstraints bypass bug in grand
>> style.
> 
> Applications can do that now by setting the right flag, as Viktor pointed 
> out.  I think it's too late to make the default change for 1.1

Well, to be fair, I was proposing a new flag.  We don't yet have a flag to
suppress processing of CN in the absence of DNS-ID SANs.

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #3502] nameConstraints bypass bug

[Viktor Dukhovni]

On Mon, May 30, 2016 at 06:56:17PM +, Rich Salz via RT wrote:

> If there is no altname and there is a CN, we cannot assume that the CN is a
> hostname. Yes, for WebPKI this is true, but WebPKI has deprecated
> cn-as-hostname for more than a decade and mandated SAN names.

OpenSSL master supports internal host name checks via SSL_add1_host(),
X509_VERIFY_PARAM_set1_host(), or (less recommended) X509_check_host().
Various flags modify the behaviour of the built-in name checks:

SSL_set_hostflags(3)
X509_VERIFY_PARAM_set_hostflags(3)

In particular, we support the X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT
flag to make it possible to always consider the subject CN even
when DNS SANs are present.  That flag is off by default and should
not be used:

https://tools.ietf.org/html/rfc6125#section-6.3

  Security Warning: A client MUST NOT seek a match for a reference
  identifier of CN-ID if the presented identifiers include a DNS-ID,
  SRV-ID, URI-ID, or any application-specific identifier types
  supported by the client.

Should there perhaps also be a new

X509_CHECK_FLAG_NEVER_CHECK_SUBJECT

flag that would ask us to never match the subject CN against DNS
reference identifiers?  And what should the default behaviour be?
(Should the new flag be on by default, requiring an explicit call
to SSL_set_hostflags(3) or X509_VERIFY_PARAM_set_hostflags(3) to
override the flag?)

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

Re: [openssl-dev] 1.1.0 pre5 seems to ignore CIPHER_SERVER_PREFERENCE

[Viktor Dukhovni]

> On May 26, 2016, at 9:44 AM, Angus Robertson - Magenta Systems Ltd 
>  wrote:
> 
> I have two custom Windows web sites, running released and beta versions
> of OpenSSL.  The beta version only gets an A- score with SSL Labs,
> whereas the release version gets A+.  
> 
> https://www1.telecom-tariffs.co.uk/serverinfo.htm
> 
> shows server status, and that it's running OpenSSL 1.1.0-pre5 (beta) 19
> Apr 2016, SSL Labs says: 'Cipher Suites (sorted by strength as the
> server has no preference;)  The server does not support Forward Secrecy
> with the reference browsers. Grade reduced to A-.'
> 
> https://www.telecom-tariffs.co.uk/serverinfo.htm
> 
> is the main live server running OpenSSL 1.0.2h 3 May 2016, and gets a
> score A+ saying 'Cipher Suites (SSL 3+ suites in server-preferred
> order)'.

Sites like SSL Labs sometimes have bugs, and also your server configuration
may lack DHE or ECDHE parameters.  In any case, OpenSSL 1.1.0 beta does support
server preference, and I don't think any recent commits either broke or fixed
this.

Testing against with Postfix compiled against HEAD I see:

   # postconf -e "tls_preempt_cipherlist = no"
   # postfix reload
   postfix/postfix-script: refreshing the Postfix mail system

   # posttls-finger -Lsummary -lencrypt -c -o "tls_medium_cipherlist = 
AES128-SHA:AES256-SHA" "[localhost]:25"
   posttls-finger: Untrusted TLS connection established to 
localhost[127.0.0.1]:25: TLSv1.2 with cipher AES128-SHA (128/128 bits)

   # postconf -e "tls_preempt_cipherlist = yes"
   # postfix reload
   postfix/postfix-script: refreshing the Postfix mail system
   # posttls-finger -Lsummary -lencrypt -c -o "tls_medium_cipherlist = 
AES128-SHA:AES256-SHA" "[localhost]:25"
   posttls-finger: Untrusted TLS connection established to 
localhost[127.0.0.1]:25: TLSv1.2 with cipher AES256-SHA (256/256 bits)

Which shows the server preference in effect for the second connection (AES256 
used despite client's preference for AES128).

-- 
Viktor.

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

Re: [openssl-dev] How to get SSL version from SSL_SESSION using OpenSSL-1.1.x?

[Viktor Dukhovni]

On Thu, May 26, 2016 at 09:58:09PM +, Viktor Dukhovni wrote:

> The following should work:
> 
> const char *get_session_protocol(SSL_CTX *ctx, SSL_SESSION *session)
> {
>   const char *protocol;
>   SSL_CTX *tmp_ctx = NULL;
> 
>   /* Typically you'd pass in a suitable non-NULL ctx */
>   if (ctx == NULL)
>   ctx = tmp_ctx = SSL_CTX_new(TLS_method());
> 
>   ssl = SSL_new(ctx);
>   SSL_set_session(ssl, session);
>   protocol = SSL_get_version(ssl);
> 
>   SSL_free(ssl);
>   SSL_CTX_free(tmp_ctx);
> 
>   return protocol;
> }

But it does not, sorry about that.  The session version is not
directly copied to the SSL object.

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

Re: [openssl-dev] How to get SSL version from SSL_SESSION using OpenSSL-1.1.x?

[Viktor Dukhovni]

On Thu, May 26, 2016 at 10:45:54PM +0100, Matt Caswell wrote:

> > Using OpenSSL-1.0.x, I currently use:
> > 
> >   ssl_version = sess->ssl_version;
> > 
> > However, I don't see an equivalent accessor in the 1.1.x APIs.  Have I
> > missed something, or does such a thing not exist yet?
> 
> I don't think such a thing exists at the moment. Out of interest why do
> you need it?

The following should work:

const char *get_session_protocol(SSL_CTX *ctx, SSL_SESSION *session)
{
const char *protocol;
SSL_CTX *tmp_ctx = NULL;

/* Typically you'd pass in a suitable non-NULL ctx */
if (ctx == NULL)
ctx = tmp_ctx = SSL_CTX_new(TLS_method());

ssl = SSL_new(ctx);
SSL_set_session(ssl, session);
protocol = SSL_get_version(ssl);

SSL_free(ssl);
SSL_CTX_free(tmp_ctx);

return protocol;
}

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

Re: [openssl-dev] [openssl.org #4458] "implicitly declared function" warnings due to missing include

[Viktor Dukhovni]

On Wed, May 25, 2016 at 09:46:02PM +, Richard Levitte via RT wrote:

> I don't get such warnings. Can you tell me what system and with what tool 
> chain
> (including versions)?

I think that the report is correct, we must be getting away with 
on most platforms.  On NetBSD, for example,  includes 
when _NETBSD_SOURCE is defined true, which requires:

#if !defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \
!defined(_XOPEN_SOURCE) && !defined(_NETBSD_SOURCE)
#define _NETBSD_SOURCE 1
#endif

So generally you get the extended features, but not always.  The
fix might be:

diff --git a/e_os.h b/e_os.h
index 1c4c204..4b3e6fd 100644
--- a/e_os.h
+++ b/e_os.h
@@ -475,6 +475,8 @@ struct servent *PASCAL getservbyname(const char *, const 
char *);
 #  define strcasecmp OPENSSL_strcasecmp
 #  define strncasecmp OPENSSL_strncasecmp
 #  define OPENSSL_IMPLEMENTS_strncasecmp
+# else
+#  include 
 # endif
 
 /* vxworks */

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

Re: [openssl-dev] [openssl.org #4540] openssl make test

[Viktor Dukhovni]

On Thu, May 12, 2016 at 09:58:25PM +, Stephen Henson via RT wrote:

> It's caused by the S/MIME test certificates expiring. This is fixed in commit
> 24762dee178bace3c3 either apply that, use a recent snapshot or just copy the
> test/smime-certs directory from a recent snapshot.

It might make sense to create an updated source tarball.  Same
underlying OpenSSL patch level (since it is just the tests, not
the resulting code that's changing).  Don't know whether we've
any process in place for doing that...

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

Re: [openssl-dev] 1.0.1t: CMS => PKCS#7 compatibility tests: signed content DER format, RSA key: verify error

[Viktor Dukhovni]

> On May 10, 2016, at 11:45 PM, Claus Assmann  wrote:
> 
> make test fails on OpenBSD and FreeBSD (8.4):
> 
> CMS => PKCS#7 compatibility tests
> signed content DER format, RSA key: verify error
> *** Error 1 in test (Makefile:330 'test_cms')
> 
> more cms.err
> Verification failure
> 34371851688:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify 
> error:pk7_smime.c:328:Verify error:certificate has expired
> 
> Is that a known problem?  If it isn't specific to my setup, maybe
> it can be fixed for the next release?

Some of the certs in the 1.0.x test suite are getting old, and it looks
like some have expired.  In "master", I generated new certificates for
various tests with a 100-year lifetime.  Though some of the tests may
still be using older certs there too.  We'll flush these out as we find
them.  Thanks for the report.

-- 
Viktor.

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

Re: [openssl-dev] where is PEM_read_bio_X509_AUX()

[Viktor Dukhovni]

[ Redirecting to openssl-us...@openssl.org ]

On Tue, Apr 19, 2016 at 01:11:38AM +, CHOW Anthony wrote:

> I am trying to do “openssl verify –CAfile server.pem” and the command hang.

It is supposed to hang (reading standard input) when (incorrectly)
invoked this way.  You've left out the CAfile filename.  The correct
way to verify a certificate is:

$ trusted=ta.pem
$ untrusted=intermediate.pem
$ subject=server.pem
$ openssl verify -CAfile $trusted -untrusted $untrusted $subject

where 

 * "ta.pem" contains your trust-anchor (root CA) certificates,
 * "intermediate.pem" contains any intermediate certificates needed to
build a trust path from a root down to the server certificate,
 * "server.pem" contains the subject certificate to be verified.

Leave out the "-untrusted $untrusted" option if you're verifying
a certificate that is directly issued by a trust-anchor.

With a sufficiently recent version of OpenSSL replace "-CAfile
$trusted" with "-trusted $trusted" to make sure you're not
inadvertently using any of the default trust-anchors installed on
your system.

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

Re: [openssl-dev] TLSv1.3

[Viktor Dukhovni]

On Sun, May 08, 2016 at 12:15:56PM +0100, Alessandro Ghedini wrote:

> I know that I'm probably getting way ahead of myself here, but I thought it
> would be interesting to start looking into adding TLS 1.3 support to OpenSSL
> (for post 1.1.0 of course).

Even after 1.1.0, TLS 1.3 might not be the highest priority item
on the list.  We still need to introduce a suitable read/write
buffer abstraction into OpenSSL and migrate all the code that
serializes and de-serializes data from pointer-arithmetic to

read, write, peek, rewind, clear, ...

operations on suitably abstracted "buffer with offset" objects.

In particular, the ASN.1 code needs to be updated to use safe buffer
management, and the SSL code needs to use a safe buffer API for
both reads and writes.  More bits of libcrypto are likely in scope,
for example EVP.

Though much cleanup has already taken place in 1.1.0, we still need
to do more, and I would prefer to see TLS 1.3 rest on more solid
foundations.

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

Re: [openssl-dev] null byte in hostname validation.

[Viktor Dukhovni]

On Wed, May 04, 2016 at 03:04:51PM +0200, none wrote:

> Hello, where are the parts of the code that check if a null byte is used in
> a string part of a x509 certificate ?
> 
> This is purely informative. I already know about
> https://www.openssl.org/docs/manmaster/crypto/X509_check_host.html. However
> I failed to find in which function and source file that part is located.

See crypto/x509v3/v3_utl.c:

X509_check_host()
X509_check_email()
equal_nocase()  (just in case :-)

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

Re: [openssl-dev] Storing session in file and reusing at client side

[Viktor Dukhovni]

On Mon, May 02, 2016 at 12:23:25PM +0530, Shubham Chauhan wrote:

> I wanted to store the freshly negotiated ssl/tls session in a file and
> reuse it (via SSL_set_session()), in the next handshake. I was not able to
> do that since the handshake got terminated giving a fatal error - illegal
> parameters (47).

Client-side sessions can be serialized via i2d_SSL_SESSION and the
resulting binary data can be stored in a file for reuse by a client
via d2i_SSL_SESSION() followed by SSL_set_session() (which copies
the session, so you can free the session obtained via d2i at that
point).

Of course the client needs to want to reconnect to the same SSL
peer with the same security policy, otherwise session reuse is
unwise.

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

Re: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Viktor Dukhovni]

> On Apr 30, 2016, at 5:26 PM, Salz, Rich  wrote:
> 
>> Since this is a MS IIS 7.0 server I would argue that it'd be in the interest 
>> of
>> openssl to handle the situation rather than accept this scenario - since IIS 
>> is
>> likely powering more than a few hosts?
> 
> It's a known bug, and openssl can work-around the bug by configuring as 
> described.

To be clear, it is a known issue in some F5 load-balancers that has been 
addressed
since, and a few other rather unusual systems.  All systems that have trouble 
with
the larger TLS client HELLO should have been patched by now, and the problem is
entirely on their end.

I should also add that in OpenSSL 1.1.0 a lot of TLS ciphers that are obsolete
or unnecessary baggage have been phased out.  So the 1.1.0 release may well
be more interoperable with such servers.

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Viktor Dukhovni]

On Tue, Apr 26, 2016 at 12:55:28PM -0500, Douglas E Engert wrote:

> Adding the test "if (n != rsa->n)" before the BN_free in the RSA_set0_key
> would catch this.

The correct test is to return an error in that case, not to skip
the free.  The caller is doing the wrong thing, and we should not
silently ignore the mistake.

There may be other pointers that the caller does not own that he
might be tempted to pass into these functions, say get0 the data
from one RSA object and attempt to set0 the same parameters on
another.

The only systemic fix is much more complex.  We'd need to manage
and set "library-owned" boolean fields in all the structures returned
by get0 functions and refuse to accept these in "set0" functions.

Thus a new() constructor would produce a caller owned structure,
as would a get1() accessor, but a get0() access would return a
library owned structure, which would be unsuitable for a set0()
call that takes ownership.

Implementing this pattern would be a major overhaul of the library.

For now, yes we could detect just one class of mistake, but I
don't think we should "correct" the mistake, rather we should
report it as such to the caller.

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

Re: [openssl-dev] SSL transfer connection (SSL_dup, SSL_up_ref, SSL_free)

[Viktor Dukhovni]

> On Apr 25, 2016, at 11:18 PM, Alex Hultman  wrote:
> 
> Thanks for the answer. I actually found a working solution just a couple of 
> minutes after I posted but I still wanted to hear what you recommended. I 
> just did ssl->references++; and also the same on the attached BIO's before 
> SSL_set_fd. This works perfectly and I'm able to take over the SSL connection 
> even after the original server "destroys" their socket.

I would not also increment the reference counts on the BIOs except for any that 
are explicitly freed by the other thread.  You be introducing a memory and file 
descriptor leak.

-- 
Viktor.

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

Re: [openssl-dev] [Bug] OpenSSL does not send short messages

[Viktor Dukhovni]

[ This question belongs on openssl-users, not openssl-dev.  Please
  reply only to openssl-users. ]

On Tue, Apr 26, 2016 at 05:17:46AM +0200, Alex Hultman wrote:

> SSL_write followed by SSL_shutdown does not actually send the data passed
> to SSL_write if the total data size sent is less than (on my system) 7-8
> bytes.

This does not happen in "openssl s_client".  You're likely doing
something wrong.

In one window I start an openssl server:

$ cipher=ADH-DES-CBC3-SHA
$ seclev= # Make that seclev=":@SECLEVEL=0" with OpenSSL 1.1.0 or later
$ openssl s_server -quiet -cipher "$cipher$seclev" -nocert -accept 12345

I another window I start a client:

$ cipher=ADH-DES-CBC3-SHA
$ seclev= # Make that seclev=":@SECLEVEL=0" with OpenSSL 1.1.0 or later
echo XXX | openssl s_client -debug -no_ign_eof -cipher "$cipher$seclev" 
-connect localhost:12345

On the server side I see the expected output:

XXX

On the client side after lots of handshake messages:

>>> ??? [length 0005]
17 03 03 00 24
write to 0x7f7f8bd003d0 [0x7f7f8c80b203] (41 bytes => 41 (0x29))
 - 17 03 03 00 24 c2 19 ea-c6 f1 a8 c7 74 31 50 3d   $...t1P=
0010 - a1 2f fb f0 d5 4d 2e 85-e0 6a 18 86 27 6a 09 1d   ./...M...j..'j..
0020 - de 98 4e 69 05 57 0f 4c-93..Ni.W.L.
DONE
>>> ??? [length 0005]
15 03 03 00 24
write to 0x7f7f8bd003d0 [0x7f7f8c80b203] (41 bytes => 41 (0x29))
 - 15 03 03 00 24 d2 94 f8-11 dd 69 81 f7 ab cc 8c   $.i.
0010 - c4 13 4c 80 24 d7 50 10-b9 62 74 d7 21 86 16 78   ..L.$.P..bt.!..x
0020 - b4 83 87 da 5e 2f d9 5d-34^/.]4
>>> TLS 1.2Alert [length 0002], warning close_notify
01 00

The first of these is the "XXX" encrypted to 16 bytes, and padded
with a 20-byte SHA1 MAC (the server and client negotiated TLS 1.2
with Encrypt-then-Mac).  The second is the encrypted shutdown alert.

> Is this known behavior?

No.

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

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Viktor Dukhovni]

On Mon, Apr 25, 2016 at 05:45:05PM +, Salz, Rich wrote:

> After a "set0" call, set your pointer to NULL, it's no longer yours :)

That half of the ruleset.  The other half is:

  You must "own" any object passed to a set0 call that takes
  ownership of its argument (we have a few that don't take ownership,
  perhaps they should be renamed to just "set").  In particular,
  objects obtained via "get0" calls MUST NOT then be used in "set0"
  calls that expect to take ownership of the argument.

Hdd OpenSSL been written in Rust we'd be able to make all this
explicit, and have the compiler enforce the rules.  That's of course
impractical, we provide a C API to other C applications and libraries.

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

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Viktor Dukhovni]

On Mon, Apr 25, 2016 at 07:21:56PM +0200, Richard Levitte wrote:

> openssl-users> Perhaps the documentation can be made more clear.  If users 
> really
> openssl-users> need an interface for modifying a subset of the components of 
> an
> openssl-users> already initialized key, then (if we don't already) we should
> openssl-users> support NULL values as "do not change", provided these are 
> already
> openssl-users> set.
> 
> Doesn't this turn them into individual parameter calls, in practice?
> I.e. the exact thing we chose not to make?

No.  We still won't support incomplete initialization, but can
support after the fact partial modification.

> There isn't much difference between this:
> 
> RSA_set0_key(rsa, n, NULL, NULL);
> RSA_set0_key(rsa, NULL, e, NULL);
> RSA_set0_key(rsa, NULL, NULL, d);
> 
> and something like this:
> 
> RSA_set0_n(rsa, n);
> RSA_set0_e(rsa, e);
> RSA_set0_d(rsa, d);

There is, if the NULL calls fail when the key is not already
initialized.

> The only difference is that with the former, you get two-in-one, as it
> also works as a function to set all three numbers in one go.

The 3-slot function is I think cleaner.

I'll leave the decision of whether and when to support NULL parameters
to the folks working on that code, but it is pretty clear that one
must not pass an object one does not "own", such as one returned
from a "get0" function, to a function that expects to take ownership
of the indicated object.

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

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Viktor Dukhovni]

On Mon, Apr 25, 2016 at 02:08:09PM +, Richard Levitte via RT wrote:

> I'm not sure how I'd change the following:
> 
> Calling this function transfers the memory management of the values to the
> RSA object, and therefore the values that have been passed in should not
> be freed by the caller after this function has been called.
> 
> That in itself hasn't changed, all that's being done is to correct a
> bug in the memory management.  But if you have a good suggestion for a
> change in that sentence, I'm all ears.

There is no bug.  It is not valid to transfer ownership of an object the
caller does not own.

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

Re: [openssl-dev] [openssl.org #4518] OpenSSL-1.1.0-pre5 RSA_set0_key and related RSA_get0_*, RSA_set0_*, DSA_set0_* and DSA_get0_* problems

[Viktor Dukhovni]

On Mon, Apr 25, 2016 at 01:39:09PM +, Richard Levitte via RT wrote:

> rt> I agree it shouldn't happen, but do we want to protect against that?  I 
> could be convinced either way.
> 
> Ah ok...  sorry, I misread the intention.
> 
> Agreed that we could make sure not to free the pointers in that case.

No, once "n" or "e" has been passed to this "set0" function, the
caller no longer owns the storage, and in particular is not free
to pass these any set0 functions that similarly take ownership
of the storage.

Perhaps the documentation can be made more clear.  If users really
need an interface for modifying a subset of the components of an
already initialized key, then (if we don't already) we should
support NULL values as "do not change", provided these are already
set.

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

[openssl-dev] [openssl.org #4502] CT todos

[Viktor Dukhovni via RT]

Beyond the suggested changes to SCT_LIST_validate() et. al.
and documentation, IIRC at some point or other I noted that
the chain verification status observed in resumed sessions
may not be correct if handshakes without valid SCTs are
allowed to complete and perhaps get reused.

Even without resumption, applications typically expect to
find out chain validity via SSL_get_verify_result().

This suggests the view that SCT validation is a late phase
of chain validation, and that if SCT processing is enabled,
but no valid SCTs are presented, while the verify result is
X509_V_OK, it perhaps ought to be set to some (new) error
value, and as a result remain set in resumed sessions.

This means that the difference between the permissive and
the strict callback would be only in the return value, both
would still look for at least one valid SCT and set an
X509_V_ERR_<...> if still X509_V_OK (do not override any
prior X509 error).

It is unfortunate that we're doing SCT at the SSL layer
and not the X.509 layer, but sadly it seems that not all
the SCTs are available at the time we're processing the
peer's certificate message.  (stapled OCSP is after
the chain IIRC).

So this issue should be dealt with (or decided to be a non
issue) in the next few days before beta2.

-- 
Viktor.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4502
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4497] openssl ciphers app possible bug

[Viktor Dukhovni via RT]

> On Apr 2, 2016, at 10:05 AM, Daniel Gruszczyk via RT  wrote:
> 
> Hi,I was playing with a ciphers app to create example list of suites. Looking 
> at the website (https://openssl.org/docs/manmaster/apps/ciphers.html) if I 
> run one of the examples there:
> openssl ciphers -v '3DES:+RSA'I supposed to get a list of 3DES ciphers with 
> any RSA ones at the end of the list (if I can read correctly).

You're forgetting about the distinction between "kRSA" and "aRSA".
The "RSA" cipher string is a synonym for "kRSA" (RSA key exchange),
not "aRSA" (RSA authentication).

This documented in ciphers(1):

   kRSA, RSA
   cipher suites using RSA key exchange.

   ...

   aRSA
   cipher suites using RSA authentication, i.e. the certificates carry 
RSA keys.

-- 
Viktor.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4497
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4497] openssl ciphers app possible bug

[Viktor Dukhovni]

> On Apr 2, 2016, at 10:05 AM, Daniel Gruszczyk via RT  wrote:
> 
> Hi,I was playing with a ciphers app to create example list of suites. Looking 
> at the website (https://openssl.org/docs/manmaster/apps/ciphers.html) if I 
> run one of the examples there:
> openssl ciphers -v '3DES:+RSA'I supposed to get a list of 3DES ciphers with 
> any RSA ones at the end of the list (if I can read correctly).

You're forgetting about the distinction between "kRSA" and "aRSA".
The "RSA" cipher string is a synonym for "kRSA" (RSA key exchange),
not "aRSA" (RSA authentication).

This documented in ciphers(1):

   kRSA, RSA
   cipher suites using RSA key exchange.

   ...

   aRSA
   cipher suites using RSA authentication, i.e. the certificates carry 
RSA keys.

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #4489] PATCH: fix Windows deprecated strdup in crypto\conf\conf_lib.c

[Viktor Dukhovni via RT]

> On Mar 28, 2016, at 4:38 AM, noloa...@gmail.com via RT  
> wrote:
> 
> On Windows, the fix below also depends upon the patch from Issue 4488
> ("The POSIX name for this item is deprecated. Instead, use the ISO C++
> conformant name...").
> 
> This patch below also fixes some problems with the older standards on
> Fedora, BSD and Linux.
> 
> $ cat conf_lib.patch
> diff --git a/crypto/conf/conf_lib.c b/crypto/conf/conf_lib.c
> index f197714..7bc3ac0 100644
> --- a/crypto/conf/conf_lib.c
> +++ b/crypto/conf/conf_lib.c
> @@ -392,7 +392,7 @@ void
> OPENSSL_INIT_set_config_filename(OPENSSL_INIT_SETTINGS *settings,
>   const char *config_file)
> {
> free(settings->config_name);
> -settings->config_name = config_file == NULL ? NULL : strdup(config_file);
> +settings->config_name = config_file == NULL ? NULL :
> OPENSSL_strdup(config_file);
> }
> #endif

If you're going to change strdup -> OPENSSL_strdup, then the previous
line needs to also change free -> OPENSSL_free.

-- 
Viktor.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4489
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4489] PATCH: fix Windows deprecated strdup in crypto\conf\conf_lib.c

[Viktor Dukhovni]

> On Mar 28, 2016, at 4:38 AM, noloa...@gmail.com via RT  
> wrote:
> 
> On Windows, the fix below also depends upon the patch from Issue 4488
> ("The POSIX name for this item is deprecated. Instead, use the ISO C++
> conformant name...").
> 
> This patch below also fixes some problems with the older standards on
> Fedora, BSD and Linux.
> 
> $ cat conf_lib.patch
> diff --git a/crypto/conf/conf_lib.c b/crypto/conf/conf_lib.c
> index f197714..7bc3ac0 100644
> --- a/crypto/conf/conf_lib.c
> +++ b/crypto/conf/conf_lib.c
> @@ -392,7 +392,7 @@ void
> OPENSSL_INIT_set_config_filename(OPENSSL_INIT_SETTINGS *settings,
>   const char *config_file)
> {
> free(settings->config_name);
> -settings->config_name = config_file == NULL ? NULL : strdup(config_file);
> +settings->config_name = config_file == NULL ? NULL :
> OPENSSL_strdup(config_file);
> }
> #endif

If you're going to change strdup -> OPENSSL_strdup, then the previous
line needs to also change free -> OPENSSL_free.

-- 
Viktor.

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

Re: [openssl-dev] Testing for a type with a define in e_os2.h?

[Viktor Dukhovni]

On Sat, Mar 26, 2016 at 06:14:05PM -0400, Jeffrey Walton wrote:

> e_os2.h has this around line 260:
> 
> # if defined(OPENSSL_SYS_UEFI) && !defined(ssize_t)
> #  define ossl_ssize_t int
> #  define OSSL_SSIZE_MAX INT_MAX
> # endif
> 
> I don't believe you can test for a type by using 'defined(t)'. Also
> see 
> http://stackoverflow.com/questions/12558538/how-can-i-check-a-certain-type-is-already-defined-in-c-compiler.

Thanks for the heads-up.  Perhaps that condition should have been
defined(ossl_ssize_t).  In any case, if UEFI code runs in 32-bit
mode, then likely the additional condition is not (or rarely) needed
at present.

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

Re: [openssl-dev] [openssl.org #4476] PATCH: fix cast-alignment of "struct lhash_st *"

[Viktor Dukhovni]

On Thu, Mar 24, 2016 at 06:41:34PM +, Salz, Rich via RT wrote:

> This looks like a good change.
> 
> > This clears what looks to be hundreds of alignment related warnings like
> > below.
> > 
> > $ git diff include/openssl/lhash.h
> > diff --git a/include/openssl/lhash.h b/include/openssl/lhash.h index
> > 2edd738..5da5054 100644
> > --- a/include/openssl/lhash.h
> > +++ b/include/openssl/lhash.h
> > @@ -180,7 +180,7 @@ void lh_node_usage_stats_bio(const _LHASH *lh, BIO
> > *out);  # define LHASH_OF(type) struct lhash_st_##type
> > 
> >  # define DEFINE_LHASH_OF(type) \
> > -LHASH_OF(type) { int dummy; }; \
> > +LHASH_OF(type) { unsigned long dummy; }; \
> >  static ossl_inline LHASH_OF(type) * \
> >  lh_##type##_new(unsigned long (*hfn)(const type *), \
> >  int (*cfn)(const type *, const type *)) \
> 
> Does changing it to "void *dummy" also work?

Not necessarily.  A union might be more comprehensive.

LHASH_OF(type) {
union {
void *v;
unsigned long long ull;
uint64_t u64;
long double ld;
} u;
};

using whatever types we're sure to have on all supported platforms.

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

Re: [openssl-dev] [openssl.org #4473] Compile errors when compiling with C++ compiler

[Viktor Dukhovni]

> On Mar 24, 2016, at 12:38 AM, noloa...@gmail.com via RT  
> wrote:
> 
> I can understand lack of resources.
> 
> Lack of interest can be dealt with in the engineering process. Place a
> quality gate, and make the code pass through it. I'd wager folks will
> take interest if/when it blocks a release.

Lack of relevance.  C++ is NOT C.  There many subtle and not so subtle
differences.  OpenSSL is written in C.  Use a C compiler.

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #4473] Compile errors when compiling with C++ compiler

[Viktor Dukhovni via RT]

> On Mar 24, 2016, at 12:38 AM, noloa...@gmail.com via RT  
> wrote:
> 
> I can understand lack of resources.
> 
> Lack of interest can be dealt with in the engineering process. Place a
> quality gate, and make the code pass through it. I'd wager folks will
> take interest if/when it blocks a release.

Lack of relevance.  C++ is NOT C.  There many subtle and not so subtle
differences.  OpenSSL is written in C.  Use a C compiler.

-- 
Viktor.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4473
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4473] Compile errors when compiling with C++ compiler

[Viktor Dukhovni via RT]

> On Mar 23, 2016, at 7:47 PM, noloa...@gmail.com via RT  
> wrote:
> 
> I'm not sure if this is a supported configuration, but I'm guessing
> there are going to be users in the filed who find themselves in it,
> like http://stackoverflow.com/q/36188982.
> 
> Working from the tip of Master...
> 
> $ export CC=g++
> $ ./config
> ...
> $ make

C is not a subset of C++ and g++ is not a C-compiler.  The user would
also have problems using a Fortran or Pascal compiler.

-- 
Viktor.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4473
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4473] Compile errors when compiling with C++ compiler

[Viktor Dukhovni]

> On Mar 23, 2016, at 7:47 PM, noloa...@gmail.com via RT  
> wrote:
> 
> I'm not sure if this is a supported configuration, but I'm guessing
> there are going to be users in the filed who find themselves in it,
> like http://stackoverflow.com/q/36188982.
> 
> Working from the tip of Master...
> 
> $ export CC=g++
> $ ./config
> ...
> $ make

C is not a subset of C++ and g++ is not a C-compiler.  The user would
also have problems using a Fortran or Pascal compiler.

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #4467] SSL_Connect crashed

[Viktor Dukhovni via RT]

> On Mar 21, 2016, at 11:51 AM, Tiantian Liu via RT  wrote:
> 
> 
> srp_ctx = {SRP_cb_arg = 0x0, TLS_ext_srp_username_callback = 0, 
> SRP_verify_param_callback = 0, SRP_give_srp_client_pwd_callback = 0,
>login = 0x44454c4c , N = 0x9a285f8, g = 
> 0x61, s = 0x9a29820, B = 0xdbd150, A = 0x0, a = 0x4, b = 0x18, v = 0x18, info 
> = 0x9a298d0 "", strength = 0,
>srp_Mask = 0}
> (gdb) n
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x008283cc in ssl3_connect () from /usr/lib/libssl.so.1.0.0
> (gdb) quit
> 
> The SSL structure was returned by SSL_new(), and we didn't touch the SSL 
> structure before we calling SSL_Connect().
> The only suspicious value I found is the  'out of bounds' error upon 'login' 
> field. But I don't think it caused the crash.

Interestingly, "0x44454c4c" is "DELL".  In OpenSSL the SSL_new() function
zeros the SSL structure when it is allocated.  So that "DELL" clobbered
the "login" pointer after the structure was allocated in SSL_new().

Are you using SRP?  One would expect the entire SRP context to be zeroed
otherwise...  Either something is clobbering memory, or you may be using
SRP incorrectly.

-- 
Viktor.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4467
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4467] SSL_Connect crashed

[Viktor Dukhovni]

> On Mar 21, 2016, at 11:51 AM, Tiantian Liu via RT  wrote:
> 
> 
> srp_ctx = {SRP_cb_arg = 0x0, TLS_ext_srp_username_callback = 0, 
> SRP_verify_param_callback = 0, SRP_give_srp_client_pwd_callback = 0,
>login = 0x44454c4c , N = 0x9a285f8, g = 
> 0x61, s = 0x9a29820, B = 0xdbd150, A = 0x0, a = 0x4, b = 0x18, v = 0x18, info 
> = 0x9a298d0 "", strength = 0,
>srp_Mask = 0}
> (gdb) n
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x008283cc in ssl3_connect () from /usr/lib/libssl.so.1.0.0
> (gdb) quit
> 
> The SSL structure was returned by SSL_new(), and we didn't touch the SSL 
> structure before we calling SSL_Connect().
> The only suspicious value I found is the  'out of bounds' error upon 'login' 
> field. But I don't think it caused the crash.

Interestingly, "0x44454c4c" is "DELL".  In OpenSSL the SSL_new() function
zeros the SSL structure when it is allocated.  So that "DELL" clobbered
the "login" pointer after the structure was allocated in SSL_new().

Are you using SRP?  One would expect the entire SRP context to be zeroed
otherwise...  Either something is clobbering memory, or you may be using
SRP incorrectly.

-- 
Viktor.

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

Re: [openssl-dev] OpenSSL 1.1.0-pre4 change in SSL_get_version() return value

[Viktor Dukhovni]

On Thu, Mar 17, 2016 at 12:37:41AM +0200, Jouni Malinen wrote:

> Was the SSL_get_version() behavior changed on purpose in the Beta 1
> release? This function used to return "TLSv1" when TLS v1.0 was used
> while it is now in Beta 1 returning "TLSv1.0" for that case.

I missed this change in the review.  Sorry about that.  It should
perhaps be reverted for beta2.  The reported version string for
TLS 1.0 has been "TLSv1" since support for "TLS 1.0" was introduced.
It should likely stay that way.

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

Re: [openssl-dev] [openssl.org #4443] Re: VIA C7-D processor: Hang in 30-test_afalg.t

[Viktor Dukhovni]

> On Mar 17, 2016, at 8:25 PM, noloa...@gmail.com via RT  
> wrote:
> 
> Yeah, this looks fishy... According to the libc manual, 13.10 Perform
> I/O Operations in Parallel
> (https://www.gnu.org/software/libc/manual/html_node/Asynchronous-I_002fO.html):
> 
>volatile void *aio_buf
> 
>This is a pointer to the buffer with the data to
>be written or the place where the read data is
>stored.
> 
> That cast should be to a void*, not an unsigned long.

Wrong interface.  Here, OpenSSL is using "struct iocb" from the kernel ABI via
, not glibc's "struct aiocb".  In the kernel structure, the
definition is:

__u64 aio_buf;

Since OpenSSL master has "uint64_t", that would perhaps be more appropriate
than (unsigned long).

-- 
Viktor.

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

Re: [openssl-dev] OpenSSL 1.1.0-pre4 change in SSL_get_version() return value

[Viktor Dukhovni]

> On Mar 18, 2016, at 4:40 PM, Richard Moore  wrote:
> 
>  I think it is reasonable to preserve the backwards compatible "TLSv1"
> > for the string protocol version, but do we also need to preserve the
> > "TLSv1.0" in ciphers(1) output?  If so, the code needs an exception
> > that can otherwise be avoided.
> 
> I'd say that ciphers(1) is directed more at human users than on
> applications, I don't think changing it there would be a problem.
> 
> ​Well, the same underlying API change would cause breakage in Qt​. As it 
> happens I've started a new backend that is openssl 1.1 specific that means it 
> probably won't matter in this case, but I doubt Qt is the only thing using 
> this string.

The git version has reverted to fully backwards-compatible behaviour.
The protocol version is "TLSv1" and the cipher protocol versions for
the handful of PSK ciphers added with TLS 1.0 are "TLSv1.0".

-- 
Viktor.

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

Re: [openssl-dev] OpenSSL 1.1.0-pre4 change in SSL_get_version() return value

[Viktor Dukhovni]

> On Mar 16, 2016, at 6:44 PM, Viktor Dukhovni <openssl-us...@dukhovni.org> 
> wrote:
> 
>> Was the SSL_get_version() behavior changed on purpose in the Beta 1
>> release? This function used to return "TLSv1" when TLS v1.0 was used
>> while it is now in Beta 1 returning "TLSv1.0" for that case.
> 
> I missed this change in the review.  Sorry about that.  It should
> perhaps be reverted for beta2.  The reported version string for
> TLS 1.0 has been "TLSv1" since support for "TLS 1.0" was introduced.
> It should likely stay that way.

Please test ee3a6c646ff8ea6b9ada5a58f4a0e7c9b7be944b, it should restore
the status quo ante.

-- 
Viktor.

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

Re: [openssl-dev] OpenSSL 1.1.0-pre4 change in SSL_get_version() return value

[Viktor Dukhovni]

> On Mar 16, 2016, at 6:44 PM, Viktor Dukhovni <openssl-us...@dukhovni.org> 
> wrote:
> 
>> Was the SSL_get_version() behavior changed on purpose in the Beta 1
>> release? This function used to return "TLSv1" when TLS v1.0 was used
>> while it is now in Beta 1 returning "TLSv1.0" for that case.
> 
> I missed this change in the review.  Sorry about that.  It should
> perhaps be reverted for beta2.  The reported version string for
> TLS 1.0 has been "TLSv1" since support for "TLS 1.0" was introduced.
> It should likely stay that way.

The commit in question consolidated disparate functions that all
converted TLS protocol versions to strings, alas not entirely
consistently.

The "TLSv1.0" style was used in "ciphers -v" to report the protocol
version that introduced the cipher, while "TLSv1" was used in most
other contexts.

I think it is reasonable to preserve the backwards compatible "TLSv1"
for the string protocol version, but do we also need to preserve the
"TLSv1.0" in ciphers(1) output?  If so, the code needs an exception
that can otherwise be avoided.

Is it OK to change the protocol version string reported by ciphers(1)
via SSL_CIPHER_get_version() by way of SSL_CIPHER_description()?

If absolutely necessary, we can retain the legacy nomenclature, but
I'm inclined to go with a change to the cipher variant, I don't think
that compatibility there is nearly as important.

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

Re: [openssl-dev] [openssl.org #4443] Re: VIA C7-D processor: Hang in 30-test_afalg.t

[Viktor Dukhovni]

> On Mar 17, 2016, at 10:52 PM, Jeffrey Walton  wrote:
> 
> This is bad news... A 32-bit pointer's sign extension is
> implementation defined, which means it may as well be undefined
> behavior...
> 
> GCC sign extends. I think you can get around it with an intermediate
> cast to uintptr_t:
> 
>cb->aio_buf = (uint64_t)(uintptr_t)buf;

The kernel sources seem to use a cast to (unsigned long) in the system
call definitions...  Someone else will have to figure out how this is
supposed to work...

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #4429] Cannot decrypt RC4-encrypted CMS object

[Viktor Dukhovni]

On Tue, Mar 15, 2016 at 07:29:04PM +, Viktor Dukhovni wrote:

> ok 24 - encrypted content test streaming PEM format, 128 bit RC2 key
> ok 25 - encrypted content test streaming PEM format, 40 bit RC2 key

The underlying test commands amount to:

 $ cd test
 $ openssl cms -EncryptedData_encrypt -in smcont.txt -outform PEM -rc2 
-secretkey 000102030405060708090A0B0C0D0E0F -stream -out test.cms
 $ openssl cms -EncryptedData_decrypt -in test.cms -inform PEM -secretkey 
000102030405060708090A0B0C0D0E0F -out smtst.txt

For me these succeed and result in smtst.txt identical to smcont.txt.

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

Re: [openssl-dev] [openssl.org #4429] Cannot decrypt RC4-encrypted CMS object

[Viktor Dukhovni]

On Tue, Mar 15, 2016 at 07:09:36PM +, Blumenthal, Uri - 0553 - MITLL wrote:

> First of all - thank you! It is great to see useful capabilities added (I
> consider stream ciphers and AEAD modes very useful :). I fully agree that
> unsigned CMS is an invitation to trouble. If I understand correctly, the
> intended openssl use is “openssl cms -encrypt … | openssl cms -sign …” (or
> the other way around :).

These days, most people recommend encrypt then sign.  CMS and S/MIME
natively support sign-then-encrypt, but encapsulating encrypted
content as signed content as above also works.

> The only problem - now I have one test failing:
> 
> ../test/recipes/80-test_ca.t .. ok
> ../test/recipes/80-test_cms.t . 2/4

The CMS tests pass when I run them:

$ HARNESS_VERBOSE=yes make TESTS=test_cms test
( cd test;  SRCTOP=../.  BLDTOP=../.  EXE_EXT=  /usr/pkg/bin/perl 
.././test/run_tests.pl test_cms )
../test/recipes/80-test_cms.t ..
1..4
# Subtest: CMS => PKCS#7 compatibility tests
1..15
Verification successful
ok 1 - signed content DER format, RSA key
Verification successful
ok 2 - signed detached content DER format, RSA key
Verification successful
ok 3 - signed content test streaming BER format, RSA
Verification successful
ok 4 - signed content DER format, DSA key
Verification successful
ok 5 - signed detached content DER format, DSA key
Verification successful
ok 6 - signed detached content DER format, add RSA signer
Verification successful
ok 7 - signed content test streaming BER format, DSA key
Verification successful
ok 8 - signed content test streaming BER format, 2 DSA and 2 RSA keys
Verification successful
ok 9 - signed content test streaming BER format, 2 DSA and 2 RSA keys, no 
attributes
Verification successful
ok 10 - signed content test streaming S/MIME format, 2 DSA and 2 RSA keys
Verification successful
ok 11 - signed content test streaming multipart S/MIME format, 2 DSA and 2 
RSA keys
ok 12 - enveloped content test streaming S/MIME format, 3 recipients
ok 13 - enveloped content test streaming S/MIME format, 3 recipients, 3rd 
used
ok 14 - enveloped content test streaming S/MIME format, 3 recipients, key 
only used
ok 15 - enveloped content test streaming S/MIME format, AES-256 cipher, 3 
recipients
ok 1 - CMS => PKCS\#7 compatibility tests
#
# Subtest: CMS <= PKCS#7 compatibility tests
1..15
Verification successful
ok 1 - signed content DER format, RSA key
Verification successful
ok 2 - signed detached content DER format, RSA key
Verification successful
ok 3 - signed content test streaming BER format, RSA
Verification successful
ok 4 - signed content DER format, DSA key
Verification successful
ok 5 - signed detached content DER format, DSA key
Verification successful
ok 6 - signed detached content DER format, add RSA signer
Verification successful
ok 7 - signed content test streaming BER format, DSA key
Verification successful
ok 8 - signed content test streaming BER format, 2 DSA and 2 RSA keys
Verification successful
ok 9 - signed content test streaming BER format, 2 DSA and 2 RSA keys, no 
attributes
Verification successful
ok 10 - signed content test streaming S/MIME format, 2 DSA and 2 RSA keys
Verification successful
ok 11 - signed content test streaming multipart S/MIME format, 2 DSA and 2 
RSA keys
ok 12 - enveloped content test streaming S/MIME format, 3 recipients
ok 13 - enveloped content test streaming S/MIME format, 3 recipients, 3rd 
used
ok 14 - enveloped content test streaming S/MIME format, 3 recipients, key 
only used
ok 15 - enveloped content test streaming S/MIME format, AES-256 cipher, 3 
recipients
ok 2 - CMS <= PKCS\#7 compatibility tests
#
# Subtest: CMS <=> CMS consistency tests
1..27
Verification successful
ok 1 - signed content DER format, RSA key
Verification successful
ok 2 - signed detached content DER format, RSA key
Verification successful
ok 3 - signed content test streaming BER format, RSA
Verification successful
ok 4 - signed content DER format, DSA key
Verification successful
ok 5 - signed detached content DER format, DSA key
Verification successful
ok 6 - signed detached content DER format, add RSA signer
Verification successful
ok 7 - signed content test streaming BER format, DSA key
Verification successful
ok 8 - signed content test streaming BER format, 2 DSA and 2 RSA keys
Verification successful
ok 9 - signed content test streaming BER format, 2 DSA and 2 RSA keys, no 
attributes
Verification successful
ok 10 - signed content test streaming S/MIME format, 2 DSA and 2 RSA keys
Verification successful
ok 11 - signed content test streaming multipart S/MIME format, 2 DSA and 2 
RSA keys
ok 12 - enveloped content test streaming S/MIME format, 3 recipients
ok 13 - enveloped content test streaming S/MIME format, 3 recipients, 3rd 
used
ok 

Re: [openssl-dev] [openssl.org #4429] Cannot decrypt RC4-encrypted CMS object

[Viktor Dukhovni]

On Tue, Mar 15, 2016 at 06:33:32AM +, Viktor Dukhovni wrote:

> This is completely untested, may not even compile!  Enjoy.

It does seem to work, so one key remaining questions is whether it
is interoperable:

$ ./util/shlib_wrap.sh ./apps/openssl req -config apps/openssl.cnf -new 
-x509 -newkey rsa:2048 -keyout key.pem -nodes -out cert.pem -days 100 -subj 
"/CN=RC4 CMS Test"

$ ./util/shlib_wrap.sh ./apps/openssl x509 -in cert.pem -noout -serial
serial=ACD5DEDE758B9AA6
$ echo sesame > data.txt
$ ./util/shlib_wrap.sh ./apps/openssl cms -rc4 -encrypt -binary -in 
data.txt -out data.txt.cms -outform DER cert.pem
$ ./util/shlib_wrap.sh ./apps/openssl cms -decrypt -in data.txt.cms -inform 
DER -out data2.txt -inkey key.pem -recip cert.pem
$ diff -u data.txt data2.txt

$ openssl asn1parse -inform DER -in data.txt.cms
0:d=0  hl=4 l= 380 cons: SEQUENCE
4:d=1  hl=2 l=   9 prim: OBJECT:pkcs7-envelopedData
   15:d=1  hl=4 l= 365 cons: cont [ 0 ]
   19:d=2  hl=4 l= 361 cons: SEQUENCE
   23:d=3  hl=2 l=   1 prim: INTEGER   :00
   26:d=3  hl=4 l= 320 cons: SET
   30:d=4  hl=4 l= 316 cons: SEQUENCE
   34:d=5  hl=2 l=   1 prim: INTEGER   :00
   37:d=5  hl=2 l=  36 cons: SEQUENCE
   39:d=6  hl=2 l=  23 cons: SEQUENCE
   41:d=7  hl=2 l=  21 cons: SET
   43:d=8  hl=2 l=  19 cons: SEQUENCE
   45:d=9  hl=2 l=   3 prim: OBJECT:commonName
   50:d=9  hl=2 l=  12 prim: UTF8STRING:RC4 CMS Test
   64:d=6  hl=2 l=   9 prim: INTEGER   :ACD5DEDE758B9AA6
   75:d=5  hl=2 l=  13 cons: SEQUENCE
   77:d=6  hl=2 l=   9 prim: OBJECT:rsaEncryption
   88:d=6  hl=2 l=   0 prim: NULL
   90:d=5  hl=4 l= 256 prim: OCTET STRING  [HEX 
DUMP]:70BD8B31ACD24F8184A54AF52446D10898DC09E4636456B8E14B3073701CAD5226C0AA03C0AD45B7056DB0A10F01487DC4DE0D35FDE7291875D665DEBB76049C6D660C885A011949A051874DF0CCEA181F9D60BC6BB8BD989B69900E917CCE170F60A34DC77A0EEFB935E13578F3AC9703AE02D972F853DBB3302BEB28F1F8E54964E7528E9E24EEA6950535EF2D1027C31CCAEB1FAB8F454ADBEB1DB9FD2A0F61F276498E64931483FDD40E90DD956BF991C3524C9EDA70211A256BEEFED941474B26ED7A4516873A12240C505813B6BD6EDFE6ED367FEAC86AEC2602A8E1C0C5ACE9C2745FA1B6702F1550FD1ECE322CD7F165DA621E984F1186CA981829AE
  350:d=3  hl=2 l=  32 cons: SEQUENCE
  352:d=4  hl=2 l=   9 prim: OBJECT:pkcs7-data
  363:d=4  hl=2 l=  10 cons: SEQUENCE
  365:d=5  hl=2 l=   8 prim: OBJECT:rc4
  375:d=4  hl=2 l=   7 prim: cont [ 0 ]
$ tail -c8 data.txt.cms | od -tx1
000   07  c3  e2  69  a0  ab  3b  ec
010

That said, stream ciphers with unsigned CMS are especially unsafe.
Since the payload has no MAC or padding of any kind, it is trivial
to XOR any desired mask into the received plaintext:

$ < data.txt.cms perl -e '
($a, $b) = map { unpack("Q", "0$_\n") } qw(sesame unsafe);
$/ = undef; $cms = ;
substr($cms, -8) = pack("Q", unpack("Q", substr($cms, -8)) ^ $a ^ $b);
print $cms' > data.txt.cms2
$ ./util/shlib_wrap.sh ./apps/openssl cms -decrypt -in data.txt.cms2 
-inform DER -out data3.txt -inkey key.pem -recip cert.pem
$ cat data3.txt
unsafe

In the above example, a ciphertext-only transformation changes
'sesame' to 'unsafe'.  That, plus RC4's biases, make it unwise in
this context.  At the very least the CMS message MUST be signed,
and the first 256 bytes should not contain sensitive and yet
frequently transmitted content.

Don't let your children play with RC4 in CMS.

Of course, unsigned CMS payloads are also vulnerable to silent
corruption even with block ciphers in CBC mode, XOR of a mask into
a ciphertext block randomizes the plaintext of that block, but
makes a predictable change in the plaintext of the next block.

So, don't expect data integrity from unsigned CMS.

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

Re: [openssl-dev] [openssl.org #4429] Cannot decrypt RC4-encrypted CMS object

[Viktor Dukhovni]

On Mon, Mar 14, 2016 at 10:34:17PM +, Dr. Stephen Henson wrote:

> > Is there any reason why stream ciphers are not supported with CMS?
> 
> Well one reason is that I'm not aware of any standard which defines how to use
> stream ciphers with CMS.
> 
> OpenSSL should really reject these with an appropriate error. 

Mind you, it seems that e.g. BouncyCastle supports CMS EnvelopedData
with RC4 (1.2.840.113549.3.4) as the AlgorithmIdentifier, and that
OpenSSL likely produces a compatible encoding (RC4 OID and no
parameters).

In which case it may suffice to handle absent parameters for ciphers
that don't need any, and RC4 might then "just work".

In crypto/cms/cms_enc.c we have:

unsigned char iv[EVP_MAX_IV_LENGTH], *piv = NULL;
...
if (enc) {
int ivlen;
calg->algorithm = OBJ_nid2obj(EVP_CIPHER_CTX_type(ctx));
/* Generate a random IV if we need one */
ivlen = EVP_CIPHER_CTX_iv_length(ctx);
if (ivlen > 0) {
if (RAND_bytes(iv, ivlen) <= 0)
goto err;
piv = iv;
}
} else if (EVP_CIPHER_asn1_to_param(ctx, calg->parameter) <= 0) {
CMSerr(CMS_F_CMS_ENCRYPTEDCONTENT_INIT_BIO,
   CMS_R_CIPHER_PARAMETER_INITIALISATION_ERROR);
goto err;
}
...

if (piv) {
calg->parameter = ASN1_TYPE_new();
if (calg->parameter == NULL) {
CMSerr(CMS_F_CMS_ENCRYPTEDCONTENT_INIT_BIO, ERR_R_MALLOC_FAILURE);
goto err;
}
if (EVP_CIPHER_param_to_asn1(ctx, calg->parameter) <= 0) {
CMSerr(CMS_F_CMS_ENCRYPTEDCONTENT_INIT_BIO,
   CMS_R_CIPHER_PARAMETER_INITIALISATION_ERROR);
goto err;
}
}

which omits encoding parameters for ciphers with ivlen <= 0 when
encrypting (e.g. with RC4), but the first "else" clause insists on
valid parameters when decrypting.  So stream cipher support basically
boils down to what makes for valid parameters in EVP_CIPHER_asn1_param().

To that end, the below patch might make RC4 "work" (in master).
The semantic diff is quite small just return 1 when type == NULL
and we have a stream cipher with no get_asn1_parameters method.
The patch is larger because I took the opportunity to reorganize
the code a bit:

int EVP_CIPHER_asn1_to_param(EVP_CIPHER_CTX *c, ASN1_TYPE *type)
{
if (c->cipher->get_asn1_parameters != NULL)
return c->cipher->get_asn1_parameters(c, type);

if (!(c->cipher->flags & EVP_CIPH_FLAG_DEFAULT_ASN1)) {
if (type == NULL &&
EVP_CIPHER_CTX_mode(c) == EVP_CIPH_STREAM_CIPHER)
return 1;
return -1;
}

switch (EVP_CIPHER_CTX_mode(c)) {
default:
return EVP_CIPHER_get_asn1_iv(c, type);

case EVP_CIPH_WRAP_MODE:
return 1;

case EVP_CIPH_GCM_MODE:
case EVP_CIPH_CCM_MODE:
case EVP_CIPH_XTS_MODE:
case EVP_CIPH_OCB_MODE:
return -1;
}
}

This is completely untested, may not even compile!  Enjoy.

-- 
Viktor.

diff --git a/crypto/evp/evp_lib.c b/crypto/evp/evp_lib.c
index bc24d5a..8957de2 100644
--- a/crypto/evp/evp_lib.c
+++ b/crypto/evp/evp_lib.c
@@ -93,31 +93,29 @@ int EVP_CIPHER_param_to_asn1(EVP_CIPHER_CTX *c, ASN1_TYPE 
*type)
 
 int EVP_CIPHER_asn1_to_param(EVP_CIPHER_CTX *c, ASN1_TYPE *type)
 {
-int ret;
-
 if (c->cipher->get_asn1_parameters != NULL)
-ret = c->cipher->get_asn1_parameters(c, type);
-else if (c->cipher->flags & EVP_CIPH_FLAG_DEFAULT_ASN1) {
-switch (EVP_CIPHER_CTX_mode(c)) {
+return c->cipher->get_asn1_parameters(c, type);
 
-case EVP_CIPH_WRAP_MODE:
-ret = 1;
-break;
+if (!(c->cipher->flags & EVP_CIPH_FLAG_DEFAULT_ASN1)) {
+if (type == NULL &&
+EVP_CIPHER_CTX_mode(c) == EVP_CIPH_STREAM_CIPHER)
+return 1;
+return -1;
+}
 
-case EVP_CIPH_GCM_MODE:
-case EVP_CIPH_CCM_MODE:
-case EVP_CIPH_XTS_MODE:
-case EVP_CIPH_OCB_MODE:
-ret = -1;
-break;
+switch (EVP_CIPHER_CTX_mode(c)) {
+default:
+return EVP_CIPHER_get_asn1_iv(c, type);
 
-default:
-ret = EVP_CIPHER_get_asn1_iv(c, type);
-break;
-}
-} else
-ret = -1;
-return (ret);
+case EVP_CIPH_WRAP_MODE:
+return 1;
+
+case EVP_CIPH_GCM_MODE:
+case EVP_CIPH_CCM_MODE:
+case EVP_CIPH_XTS_MODE:
+case EVP_CIPH_OCB_MODE:
+return -1;
+}
 }
 
 int EVP_CIPHER_get_asn1_iv(EVP_CIPHER_CTX *c, ASN1_TYPE *type)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4429] Cannot decrypt RC4-encrypted CMS object

[Viktor Dukhovni]

On Mon, Mar 14, 2016 at 07:03:04PM +, Blumenthal, Uri - 0553 - MITLL wrote:

> >IIRC RC4 (more generally all stream ciphers) are not supported with
> >CMS, and the bug is that OpenSSL allowed you to use RC4, not that
> >the result failed to decrypt.
> 
> Is there any reason why stream ciphers are not supported with CMS?

At least in part because code does not write itself, and support
was never implemented.

The main issue seems to be related to handling of "parameters",
such as the IV for CBC ciphers.  With RC4 there is no IV, nor any
other parameters, but the CMS decoder expects parameters to be
present.

Would it work if the requirement were relaxed?  Perhaps, but that
requires someone to implement said change.

As for GCM/CCM ciphers with CMS that's described in

https://tools.ietf.org/html/rfc5084

and someone would have to implement that.

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

Re: [openssl-dev] [openssl.org #4429] Cannot decrypt RC4-encrypted CMS object

[Viktor Dukhovni]

On Mon, Mar 14, 2016 at 05:45:34PM +, Stephan Mühlstrasser via RT wrote:

> I had written a message about this issue to openssl-users, but received 
> no reaction.

IIRC RC4 (more generally all stream ciphers) are not supported with
CMS, and the bug is that OpenSSL allowed you to use RC4, not that
the result failed to decrypt.

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

Re: [openssl-dev] 1.1-pre4 documentation fails to install

[Viktor Dukhovni]

On Mon, Mar 14, 2016 at 03:28:13PM +, Blumenthal, Uri - 0553 - MITLL wrote:

> install ./doc/crypto/EVP_PKEY_set1_RSA.pod -> 
> /Users/ur20980/share/man/man3/EVP_PKEY_set1_RSA.3
> 
> IO::File=IO(0x7feb8c8029c0) around line 62: Unterminated B<...> sequence
> POD document had syntax errors at /opt/local/bin/pod2man line 68.

Try:

diff --git a/doc/crypto/EVP_PKEY_set1_RSA.pod b/doc/crypto/EVP_PKEY_set1_RSA.pod
index de31bc1..c7fd8e9 100644
--- a/doc/crypto/EVP_PKEY_set1_RSA.pod
+++ b/doc/crypto/EVP_PKEY_set1_RSA.pod
@@ -62,7 +62,7 @@ an RSA key will return B.
 EVP_PKEY_id() returns the actual OID associated with B. Historically keys
 using the same algorithm could use different OIDs. For example an RSA key could
 use the OIDs corresponding to the NIDs B (equivalent to
-B

Re: [openssl-dev] API Problems in current master

[Viktor Dukhovni]

> On Mar 13, 2016, at 10:41 AM, Rainer Jung  wrote:
> 
> The docs should be fixed, but there's:
> 
> int EVP_PKEY_id(const EVP_PKEY *pkey);
> int EVP_PKEY_base_id(const EVP_PKEY *pkey);

Thanks for the nudge:

https://github.com/openssl/openssl/commit/b36a2efd55078a5fff32b2755046b23cb3c5d8a3

-- 
Viktor.

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

[openssl-dev] Question: Make X509_V_FLAG_TRUSTED_FIRST default in 1.0.2?

[Viktor Dukhovni]

On Fri, Mar 11, 2016 at 05:54:57AM +, Viktor Dukhovni wrote:

> Absent augmentation as a "trusted certificate" for a given purpose,
> and with the application not enabling "partial chain" semantics,
> intermediate certs from the store just augment missing certificates
> from the wire, and should be verified in the same manner.  The
> changes I want to backport from 1.1.0 ensure identical treatment
> of untrusted intermediates regardless of provenance.

I have an important question for the list.  At present the pending
patches to backport from 1.1.0 to 1.0.2 do not change the default
chain construction strategy to X509_V_FLAG_TRUSTED_FIRST

commit ca9051b136284a96ea6c10ac4efd355cfc4716a0
Author: Viktor Dukhovni <openssl-us...@dukhovni.org>
Date:   Thu Feb 4 01:04:02 2016 -0500

Check chain extensions also for trusted certificates

This includes basic constraints, key usages, issuer EKUs and
auxiliary trust OIDs (given a trust suitably related to the
intended purpose).

Note, for this to work consistently, the X509_V_FLAG_TRUSTED_FIRST
flag must be set.  This is the default in 1.1.0-dev, but is likely
too big a change for the 1.0.2 stable release.

(Backport from 1.1.0-dev)

What this means is that treatment of auxiliary trust "decorations"
for intermediate CAs is not predictable unless that flag is explicitly
set by the application.  IIRC some people have been asking for this
flag to become the default (or at least requested its creation).

So I'd like to hear whether the above mentioned (pending) commit
is the right judgement call, or whether I should go ahead and update
X509_V_FLAG_TRUSTED_FIRST to be the default also in the next 1.0.2
release.

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

Re: [openssl-dev] [openssl.org #4415] test/certs/mkcert.sh uses "#! /binbash"

[Viktor Dukhovni]

On Fri, Mar 11, 2016 at 12:05:32PM +, noloa...@gmail.com via RT wrote:

> test/certs/mkcert.sh uses:
> 
> #! /bin/bash"

This shell script is only used in test development, it is not used
during either compilation or testing of OpenSSL.  It need not be
especially portable.

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

Re: [openssl-dev] [openssl.org #4409] bug OpenSSL 1.0.1p 9 Jul 2015

[Viktor Dukhovni]

On Thu, Mar 10, 2016 at 12:58:34PM +, Irena Johnson via RT wrote:

> Our clients are having trouble connecting to our GRAM server, which has a
> sha256 host certificate.

The reason for the connection failures may be unrelated to the
certificate signature algorithm.  What specific symptoms lead to
the conclusion that this is the problem?

In OpenSSL 1.0.1 sha256 is enabled by default (via SSL_library_init()
also known as OpenSSL_add_ssl_algorithms()).

> and it appears it's not compatible with sha256 encryption:

This is simply not the case.

> The command "openssl ciphers -v | grep 256" returns nothing.

Not even "AES256" ciphers?  That's rather odd, those have been
around since 0.9.8 IIRC.

And, in any case, this is the wrong test for support for SHA256 in
certificates.  Your problem is with the server certificate, not
the MAC algorithm used in TLS ciphers.

> What version of openssl should they install? Thank you for your help,

The problem is almost certainly elsewhere.  It is of course possible
to build OpenSSL with various algorithms disabled, including
"no-sha256", ... so please report the output of

$ openssl version -v -p -o -f

and "ldd" output showing the library dependencies of both the "openssl"
command, and your application.

$ ldd /usr/bin/openssl | egrep 'lib(ssl|crypto)'
$ ldd /some/executable | egrep 'lib(ssl|crypto)'

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

Re: [openssl-dev] [openssl.org #4398] BUG / 1.0.2g breaks CURL extension

[Viktor Dukhovni]

On Tue, Mar 08, 2016 at 04:09:29PM +, Thomas Brunnthaler via RT wrote:

> I am unable to recompile PHP 5.2.17 VC6 TS x86  and because of my old
> webserver (where source is not available) i cannot upgrade to any newer
> version with VC9+  Is the software change in OpenSSL so dramatic, that
> newer releases are totally incompatible with "old" software ?

No, but 1.0.2g in default builds omits three previously defined functions,

SSLv2_method(),
SSLv2_client_method(),
SSLv2_server_method().

on platforms where symbol (function name) resolution is not "lazy"
(delayed to first use), programs that can but don't in practice
use SSLv2 may not start when the library no longer provides these
functions.

> > > Is this fixed by:
> > > https://github.com/openssl/openssl/commit/133138569f37d149ed1d7641fe8c75a93fded445

The commit above restores the symbols.  If you could build that
version (checkout from git, or apply the patch) and confirm whether
the issue is resolved, that would be great.

-- 
Viktor.

commit 133138569f37d149ed1d7641fe8c75a93fded445
Author: Viktor Dukhovni <vik...@twosigma.com>
Date:   Mon Mar 7 21:10:38 2016 +

Retain SSLv2 methods as functions that return NULL

This improves ABI compatibility when symbol resolution is not lazy.

Reviewed-by: Richard Levitte <levi...@openssl.org>

diff --git a/ssl/s2_meth.c b/ssl/s2_meth.c
index b312f17..d46e2f5 100644
--- a/ssl/s2_meth.c
+++ b/ssl/s2_meth.c
@@ -74,8 +74,8 @@ IMPLEMENT_ssl2_meth_func(SSLv2_method,
  ssl2_accept, ssl2_connect, ssl2_get_method)
 #else   /* !OPENSSL_NO_SSL2 */
 
-# if PEDANTIC
-static void *dummy = 
-# endif
+SSL_METHOD *SSLv2_method(void) { return NULL; }
+SSL_METHOD *SSLv2_client_method(void) { return NULL; }
+SSL_METHOD *SSLv2_server_method(void) { return NULL; }
 
 #endif
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4398] BUG / 1.0.2g breaks CURL extension

[Viktor Dukhovni]

On Tue, Mar 08, 2016 at 01:43:48PM +, Thomas Brunnthaler via RT wrote:

> CURL not working since upgrade to 1.0.2g on windows. I use PHP 5.2.17 VC6
> x86 TS. Error Message: OS cannot load %1 or so.

Is this fixed by:


https://github.com/openssl/openssl/commit/133138569f37d149ed1d7641fe8c75a93fded445

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

Re: [openssl-dev] MacOS defaults?

[Viktor Dukhovni]

> On Mar 6, 2016, at 12:00 PM, Ben Laurie  wrote:
> 
> Hmm. So why do I see this on my macbook?
> 
> $ arch
> i386

Try "uname -m"

-- 
Viktor.

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

Re: [openssl-dev] MacOS defaults?

[Viktor Dukhovni]

> On Mar 6, 2016, at 6:20 AM, Ben Laurie  wrote:
> 
> Currently OpenSSL defaults to 32 bit in MacOS. I'm told it might be better to 
> default to 64 bit these days.
> 
> Does anyone have any views?

I support a switch to a 64bit default.

-- 
Viktor.

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

Re: [openssl-dev] cipher order

[Viktor Dukhovni]

> On Mar 4, 2016, at 3:57 PM, Emilia Käsper  wrote:
> 
> I've updated the pull to do a much more substantial cleanup.

What will @STRENGTH mean in this context?  Will ignore
the distinction between AES256 and AES128?  What does this
do to the @SECLEVEL interface which tries to provide
NIST-compatible bit strengths across multiple features?

Or we just changing the default order, and allowing
@STRENGTH to perturb it back, and @SECLEVEL to prune-away
128 leaving just 256, ...

In other words how does this fit into the larger picture?

-- 
Viktor.

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

Re: [openssl-dev] links to KDF functions from pkeyutl man are broken

[Viktor Dukhovni]

> On Mar 4, 2016, at 5:24 AM, Salz, Rich  wrote:
> 
> Yes, links across sections (apps/crypto etc) don’t work well.

We could put all the docs in a single directory.  If we were
worried about collisions, switch from:

page.html => page..html

where section is "1" or "3" as appropriate.  Links across sections
are useful.

-- 
Viktor.

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

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

[Viktor Dukhovni]

> On Mar 4, 2016, at 7:24 AM, Andy Polyakov via RT  wrote:
> 
> Fear is irrational and destructive feeling. Having faith that world is
> better than that it nothing but healthy :-) What I'm saying is that
> let's put a little bit more substance into discourse. Would anybody
> consider it *sane* programming practice to rely on partially overlapping
> buffers in *general* case? I.e. without actually *knowing* (as opposite
> to *assuming*) what's gong on? [Control question: does compiler
> guarantee order of references to memory?] As said in last message I
> don't consider it sane and even consider it natural [which means that
> I'd expect majority to not consider it sane too].

One the cool features of the OCB code some folks I know to be using
and relying on is that it supports in-place encryption.  You give
it a buffer, and it is encrypted in place.  This is specifically
promised by the API and is noticeably fast.

No idea whether this is a useful datapoint...

-- 
Viktor.

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

Re: [openssl-dev] [PATCH] Do not offer options like -ssl2, -tls1, -dtls if they are not compiled in

[Viktor Dukhovni]

> On Mar 3, 2016, at 8:07 PM, Ángel González  wrote:
> 
> They were showed in the help, but providing them failed with an
> “unknown option” error, and showed the help which listed it
> as a valid option.

The patch is not right.  For example, when TLSv1 is disabled, it is
not the case that TLSv1.1 and TLSv1.2 are disabled.  Secondly disabled
features should report that the feature is disabled, not a bad usage
message, as would be the case with a mistyped option.

> Patch against the stable 1.0.2 branch.
> 
>  apps/s_client.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/apps/s_client.c b/apps/s_client.c
> index 0c1102b..f68c581 100644
> --- a/apps/s_client.c
> +++ b/apps/s_client.c
> @@ -376,16 +376,22 @@ static void sc_usage(void)
> " -srp_strength int - minimal length in bits for N
> (default %d).\n",
> SRP_MINIMAL_N);
>  #endif
> +#ifndef OPENSSL_NO_SSL2
>  BIO_printf(bio_err, " -ssl2 - just use SSLv2\n");
> +#endif
>  #ifndef OPENSSL_NO_SSL3_METHOD
>  BIO_printf(bio_err, " -ssl3 - just use SSLv3\n");
>  #endif
> +#ifndef OPENSSL_NO_TLS1
>  BIO_printf(bio_err, " -tls1_2   - just use TLSv1.2\n");
>  BIO_printf(bio_err, " -tls1_1   - just use TLSv1.1\n");
>  BIO_printf(bio_err, " -tls1 - just use TLSv1\n");
> +#endif
> +#ifndef OPENSSL_NO_DTLS1
>  BIO_printf(bio_err, " -dtls1- just use DTLSv1\n");
> -BIO_printf(bio_err, " -fallback_scsv - send TLS_FALLBACK_SCSV\n");
>  BIO_printf(bio_err, " -mtu  - set the link layer MTU\n");
> +#endif
> +BIO_printf(bio_err, " -fallback_scsv - send TLS_FALLBACK_SCSV\n");
>  BIO_printf(bio_err,
> " -no_tls1_2/-no_tls1_1/-no_tls1/-no_ssl3/-no_ssl2 -
> turn off that protocol\n");
>  BIO_printf(bio_err,
> -- 
> 2.7.2
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
Viktor.

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

Re: [openssl-dev] 1.0.2g MacOSX x86_64 build failure (1.0.2f and 1.0.1s are fine)

[Viktor Dukhovni]

On Tue, Mar 01, 2016 at 12:50:46PM -0500, Brad House wrote:

> We have a Mac build system running an older version (10.7), targeting 10.6, 
> which is
> using this compiler:
> 
> $ cc --version
> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) 
> (LLVM build 2336.1.00)
> 
> 
> And while building 1.0.2g released today, we found a build regression for 
> x86_64, this
> regression appears to only impact 1.0.2g (1.0.1s also released today is 
> unaffected,
> as is the prior 1.0.2f, and 1.0.2g when building 32bit/i386 too is 
> unaffected).
> 
> The build error is:
> 
> cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
> -fno-common -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
> -DHAVE_DLFCN_H -isysroot /Developer/SDKs/MacOSX10.6.sdk/ 
> -mmacosx-version-min=10.6 -arch x86_64 -O3 -DL_ENDIAN -Wall 
> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
> -I/usr/local//ssl-fips-2.0.11-x86_64/include -DSHA1_ASM -DSHA256_ASM 
> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
> -DGHASH_ASM -DECP_NISTZ256_ASM -c  -o sha1-x86_64.o sha1-x86_64.s
> sha1-x86_64.s:1243:missing or invalid immediate expression `0b00011011' 
> taken as 0
> sha1-x86_64.s:1243:suffix or operands invalid for `pshufd'
> sha1-x86_64.s:1245:missing or invalid immediate expression `0b00011011' 
> taken as 0
> sha1-x86_64.s:1245:suffix or operands invalid for `pshufd'
> sha1-x86_64.s:1395:missing or invalid immediate expression `0b00011011' 
> taken as 0
> sha1-x86_64.s:1395:suffix or operands invalid for `pshufd'
> sha1-x86_64.s:1396:missing or invalid immediate expression `0b00011011' 
> taken as 0
> sha1-x86_64.s:1396:suffix or operands invalid for `pshufd'

The only plausible change from 1.0.2f to 1.0.2g that I see that
might be related to this is below.  Does it work if you revert this
change (patch -R):

commit 10c639a8a56c90bec9e332c7ca76ef552b3952ac
Author: Andy Polyakov 
Date:   Wed Feb 10 15:11:40 2016 +0100

perlasm/x86_64-xlate.pl: pass pure constants verbatim.

RT#3885

Reviewed-by: Rich Salz 
(cherry picked from commit fd7dc201d3b9d43972de6a0e659f7ef6421c99cc)

diff --git a/crypto/perlasm/x86_64-xlate.pl b/crypto/perlasm/x86_64-xlate.pl
index 9c70b8c..ee04221 100755
--- a/crypto/perlasm/x86_64-xlate.pl
+++ b/crypto/perlasm/x86_64-xlate.pl
@@ -198,8 +198,11 @@ my %globals;
if ($gas) {
# Solaris /usr/ccs/bin/as can't handle multiplications
# in $self->{value}
-   $self->{value} =~ s/(?{value} =~ s/([0-9]+\s*[\*\/\%]\s*[0-9]+)/eval($1)/eg;
+   my $value = $self->{value};
+   $value =~ s/(?{value} = $value;
+   }
sprintf "\$%s",$self->{value};
} else {
$self->{value} =~ s/(0b[0-1]+)/oct($1)/eig;

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

Re: [openssl-dev] req command crashes using config file containing passwords

[Viktor Dukhovni]

On Mon, Feb 29, 2016 at 03:51:02PM +0100, Michel wrote:

> They are failing when calling the 'req' command with a configure script
> containing input_password/output password :

Please try the patch below:

-- 
Viktor.

diff --git a/apps/req.c b/apps/req.c
index 693acc2..b128fa8 100644
--- a/apps/req.c
+++ b/apps/req.c
@@ -198,7 +198,9 @@ int req_main(int argc, char **argv)
 char *extensions = NULL, *infile = NULL;
 char *outfile = NULL, *keyfile = NULL, *inrand = NULL;
 char *keyalgstr = NULL, *p, *prog, *passargin = NULL, *passargout = NULL;
-char *passin = NULL, *passout = NULL, *req_exts = NULL, *subj = NULL;
+char *passin = NULL, *passout = NULL;
+char *nofree_passin = NULL, *nofree_passout = NULL;
+char *req_exts = NULL, *subj = NULL;
 char *template = default_config_file, *keyout = NULL;
 const char *keyalg = NULL;
 OPTION_CHOICE o;
@@ -436,15 +438,17 @@ int req_main(int argc, char **argv)
 }
 }
 
-if (!passin) {
-passin = NCONF_get_string(req_conf, SECTION, "input_password");
-if (!passin)
+if (passin == NULL) {
+passin = nofree_passin =
+NCONF_get_string(req_conf, SECTION, "input_password");
+if (passin == NULL)
 ERR_clear_error();
 }
 
-if (!passout) {
-passout = NCONF_get_string(req_conf, SECTION, "output_password");
-if (!passout)
+if (passout == NULL) {
+passout = nofree_passout =
+NCONF_get_string(req_conf, SECTION, "output_password");
+if (passout == NULL)
 ERR_clear_error();
 }
 
@@ -862,8 +866,10 @@ int req_main(int argc, char **argv)
 X509_REQ_free(req);
 X509_free(x509ss);
 ASN1_INTEGER_free(serial);
-OPENSSL_free(passin);
-OPENSSL_free(passout);
+if (passin != nofree_passin)
+OPENSSL_free(passin);
+if (passout != nofree_passout)
+OPENSSL_free(passout);
 OBJ_cleanup();
 return (ret);
 }
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev