selfserv and tstclnt on SNI

[John Jiang]

Hi,
Using NSS 3.35.

It looks tstclnt always send SNI extension, even though no option "-a".
As for selfserv, I suppose it should have an option for configuring
multiple certificates (nicknames) for server side. But I don't find it.

In addition, option "-n" means rsa_nickname, but with my testing, it also
works with the nicknames for DSA and ECDSA certificates, though such
nicknames should use options -S and -e respectively.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How do selfserv and tstclnt support ALPN?

[John Jiang]

Thanks for the clarification!

2018-02-07 22:43 GMT+08:00 Franziskus Kiefer :

> Hi,
>
> -Q was added in NSS 3.26 and adds, as described, "ALPN for HTTP/1.1
> [RFC7301]".
> There's currently non way to set a custom ALPN.
>
> Cheers
>
> On Wed, Feb 7, 2018 at 12:03 PM, John Jiang 
> wrote:
>
> > Hi,
> > I'm playing selfserv and tstclnt from a NSS 3.35 build.
> > Although selfserv introduces option "-Q" for enabling ALPN, I don't find
> > any option to allow selfserv and tstclnt to specify their application
> > protocols respectively.
> > How to make selfserv and tstclnt to negotiate application protocol?
> > Thanks!
> > --
> > dev-tech-crypto mailing list
> > dev-tech-crypto@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-tech-crypto
> >
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: how do I test if NSS supports an algorithm at build time?

[Martin Thomson]

We do this probing in NSS because we can't guarantee that the softoken
implementation matches the libssl implementation version.  Yeah,
strange world we live in, right?

The probe is a little ugly, because there isn't a straight function
you can call that says "this algorithm is supported":

This is where we filter out algorithms that we don't like:
https://searchfox.org/nss/rev/aa30a457e9cf58909c44244fa37a0d234c2914cc/lib/ssl/sslgrp.c#76

If you trace this down, it basically ends up with the code that
creates a key pair in that group:
https://searchfox.org/nss/rev/aa30a457e9cf58909c44244fa37a0d234c2914cc/lib/ssl/ssl3ecc.c#439

As you say, conditioning on version is easy enough.

On Thu, Feb 8, 2018 at 4:13 AM, Andrew Cagney  wrote:
> On 7 February 2018 at 11:45, Andrew Cagney  wrote:
>> On 7 February 2018 at 10:41, Franziskus Kiefer  wrote:
>>> You should probably try to detect this at runtime.
>>> At compile time you can simply check if SEC_OID_CURVE25519 exists and fail
>>> (or do something else) if it doesn't.
>
> If SEC_OID_CURVE25519 was a #define then a build time test would be
> easy.  Alas, it's an enum.
> So without sucking in autoconf, is there some official proxy for this.
> If all else fails there should be a version number in the header.
>
>>> At runtime you could try using SEC_OID_CURVE25519 (with your own define to
>>> 355) and have a fallback if NSS gives you an error on using it.
>
> While NSS has what I'll loosely describe as its ABI guarantee and this
> magic should work.  I'd rather to not go there.
>
> I'm more comfortable with building against version X and only accept
> version >=X at runtime.
>
> Andrew
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: how do I test if NSS supports an algorithm at build time?

[Andrew Cagney]

On 7 February 2018 at 11:45, Andrew Cagney  wrote:
> On 7 February 2018 at 10:41, Franziskus Kiefer  wrote:
>> You should probably try to detect this at runtime.
>> At compile time you can simply check if SEC_OID_CURVE25519 exists and fail
>> (or do something else) if it doesn't.

If SEC_OID_CURVE25519 was a #define then a build time test would be
easy.  Alas, it's an enum.
So without sucking in autoconf, is there some official proxy for this.
If all else fails there should be a version number in the header.

>> At runtime you could try using SEC_OID_CURVE25519 (with your own define to
>> 355) and have a fallback if NSS gives you an error on using it.

While NSS has what I'll loosely describe as its ABI guarantee and this
magic should work.  I'd rather to not go there.

I'm more comfortable with building against version X and only accept
version >=X at runtime.

Andrew
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: how do I test if NSS supports an algorithm at build time?

[Andrew Cagney]

On 7 February 2018 at 10:41, Franziskus Kiefer  wrote:
> You should probably try to detect this at runtime.
> At compile time you can simply check if SEC_OID_CURVE25519 exists and fail
> (or do something else) if it doesn't.
>
> At runtime you could try using SEC_OID_CURVE25519 (with your own define to
> 355) and have a fallback if NSS gives you an error on using it.
>
> On Wed, Feb 7, 2018 at 4:30 PM, Paul Wouters  wrote:
>
>> On Wed, 7 Feb 2018, Andrew Cagney wrote:
>>
>> I'd like to use SEC_OID_CURVE25519 but I noticed older NSS versions
>>> don't have it.
>>>
>>> What is the correct way to check for things like this at build time?
>>>
>>
>> But you'd want to check runtime, because someone might update the nss
>> install to one that does support it.
>>
>> Paul
>>
>> --
>> dev-tech-crypto mailing list
>> dev-tech-crypto@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: how do I test if NSS supports an algorithm at build time?

[Franziskus Kiefer]

You should probably try to detect this at runtime.
At compile time you can simply check if SEC_OID_CURVE25519 exists and fail
(or do something else) if it doesn't.

At runtime you could try using SEC_OID_CURVE25519 (with your own define to
355) and have a fallback if NSS gives you an error on using it.

On Wed, Feb 7, 2018 at 4:30 PM, Paul Wouters  wrote:

> On Wed, 7 Feb 2018, Andrew Cagney wrote:
>
> I'd like to use SEC_OID_CURVE25519 but I noticed older NSS versions
>> don't have it.
>>
>> What is the correct way to check for things like this at build time?
>>
>
> But you'd want to check runtime, because someone might update the nss
> install to one that does support it.
>
> Paul
>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: how do I test if NSS supports an algorithm at build time?

[Paul Wouters]

On Wed, 7 Feb 2018, Andrew Cagney wrote:


I'd like to use SEC_OID_CURVE25519 but I noticed older NSS versions
don't have it.

What is the correct way to check for things like this at build time?


But you'd want to check runtime, because someone might update the nss
install to one that does support it.

Paul
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

how do I test if NSS supports an algorithm at build time?

[Andrew Cagney]

Hi,

I'd like to use SEC_OID_CURVE25519 but I noticed older NSS versions
don't have it.

What is the correct way to check for things like this at build time?
As an aside, is there anything I should be doing to sanity check that
the runtime SO is valid for my build.

Andrew

(yes, I know about autoconf :-)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: How do selfserv and tstclnt support ALPN?

[Franziskus Kiefer]

Hi,

-Q was added in NSS 3.26 and adds, as described, "ALPN for HTTP/1.1
[RFC7301]".
There's currently non way to set a custom ALPN.

Cheers

On Wed, Feb 7, 2018 at 12:03 PM, John Jiang 
wrote:

> Hi,
> I'm playing selfserv and tstclnt from a NSS 3.35 build.
> Although selfserv introduces option "-Q" for enabling ALPN, I don't find
> any option to allow selfserv and tstclnt to specify their application
> protocols respectively.
> How to make selfserv and tstclnt to negotiate application protocol?
> Thanks!
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

How do selfserv and tstclnt support ALPN?

[John Jiang]

Hi,
I'm playing selfserv and tstclnt from a NSS 3.35 build.
Although selfserv introduces option "-Q" for enabling ALPN, I don't find
any option to allow selfserv and tstclnt to specify their application
protocols respectively.
How to make selfserv and tstclnt to negotiate application protocol?
Thanks!
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto