Subject: [wpkops] Test site

From: Rick Andrews <[email-masked]>
Date: Tue, 11 Feb 2014 10:22:31 -0800

I received this request from Mozilla:

Are you able to provide URLs for test sites with appropriate certs for
section 10), numbers f) and g)? I am unable to find any IDN TLS sites!
Also, I could do with some example "broken" SSL cert sites for 16) b).

Is anyone able to help here?

-Rick

---

From: Gary Gapinski <[email-masked]>
Date: Tue, 11 Feb 2014 14:20:09 -0500

On 02/11/2014 01:22 PM, Rick Andrews wrote:
> section 10), numbers f) and g)?
10f: /If ALPN and NPN are supported, is NPN ignored when an ALPN 
extension is also present? yes no/

A somewhat quick search does not find much other than NPN is supported 
in OpenSSL (and reputedly in NSS). Unsure about ALPN support. I am 
uncertain how precise such a test server would have to be. I can do a 
bit more searching this evening. As far as I can tell, these are 
protocols and the certs should not matter (other than being handily 
trusted).

I am also uncertain whether Apache HTTP Server augmented with mod_spdy 
would suffice, at least for NPN.

10g: /Does the product support a ServerHello larger than 255 bytes? yes no/

This will require re-re-reading the TLS 1.2 RFC followed by some casting 
about for arbitrary ServerHello capability.

> I am unable to find any IDN TLS sites!

I can probably create one. I could not find any reference to IDN in the 
questionnaire.

!!!

Sigh. I looked at the server portion of the questionnaire while making 
the above comments.

I will presume this was (Mozilla) asking about the browser section, so, 
starting over…
> section 10), numbers f) and g)? I am unable to find any IDN TLS sites!

10f: /What is the behavior when the user types in a URL using a Punycode 
name and the TLS certificate contains only the native encoding of the 
domain name?/
10g: /What is the behavior when the user types in a URL using a native 
encoding of the domain name and the TLS certificate contains only the 
Punycode name?/

I expect such a test site can be manufactured, but I cannot promise 
anything immediately. The variant certs would have to be hand crafted 
and thus self-signed (or signed by a hand-crafted CA). This is a few 
hours of work (I have not looked at IDN names for much longer than my 
one week info retention half-life) to obtain an appropriate domain name 
(punycode needs to be within an appropriate IDN TLD for browsers to 
render properly), set up a TLS HTTP service for that DNS name, and 
create the necessary specimens. I am uncertain whether OpenSSL or 
similar applications will support use of Unicode in subject CN and 
Subject Alternative Name (10f, unless I misunderstand "native encoding").

> Also, I could do with some example "broken" SSL cert sites for 16) b).

This will also require hand-crafted certs.

> Is anyone able to help here?

I will look tonight to see if there are any extant sites which offer any 
of these. The alternative is many hours of work to create the necessary 
specimens.

Regards,

Gary

---

From: Gervase Markham <[email-masked]>
Date: Tue, 11 Feb 2014 19:32:56 +0000

> of these. The alternative is many hours of work to create the necessary

If there are no such sites, what is the point of the question, and who
asked it?

Gerv

---

From: Gary Gapinski <[email-masked]>
Date: Tue, 11 Feb 2014 14:48:07 -0500

On 02/11/2014 02:32 PM, Gervase Markham wrote:
> asked it? Gerv 

I do not recall the provenance.

I suspect 10 f&g were less important (Punycode/Unicode parity) than 16, 
which was to elicit which routine conditions triggered user notification 
as well subsequent user options.

Regards,

Gary

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Feb 2014 13:20:58 -0800

> I am unable to find any IDN TLS sites!

I am in the process of seeing if I can do this for éxample.com using StartSSL. I'll report back within a day or so. (The things we do to avoid paying $20...)

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Feb 2014 16:34:45 -0800

>> I am unable to find any IDN TLS sites!

https://www.éxample.com/ (also known as https://www.xn--xample-9ua.com/) should now let you test.

--Paul Hoffman

---

From: Gervase Markham <[email-masked]>
Date: Wed, 12 Feb 2014 12:22:34 +0000

> https://www.éxample.com/ (also known as https://www.xn--xample-9ua.com/) should now let you test.

Super :-) That helps us test 10 g), but not 10 f). For 10 f), we need a
certificate which has only the native encoding of the domain name in CN
(i.e. not punycode). Can such a cert be obtained?

Gerv

---

From: Rob Stradling <[email-masked]>
Date: Wed, 12 Feb 2014 12:53:15 +0000

> (i.e. not punycode). Can such a cert be obtained?

Yes.  In fact, here's one Paul requested from us (for www.éxample.com) a 
few years ago...

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Gary Gapinski <[email-masked]>
Date: Wed, 12 Feb 2014 07:54:32 -0500

On 02/11/2014 07:34 PM, Paul Hoffman
wrote:

https://www.éxample.com/ (also known as
https://www.xn--xample-9ua.com/) should now let you test.

This is sufficient for 10g but not 10f. The certificate has only
Punycode for subject CN and SAN.

The TLS service also must
provide the CA certificate chain.

Possibly of interest: Mozilla Firefox displays the IDN name in the
URL bar; Google Chrome displays only Punycode. See also https://bugzilla.mozilla.org/show_bug.cgi?id=722299.

---

From: Gervase Markham <[email-masked]>
Date: Wed, 12 Feb 2014 13:08:15 +0000

On 12/02/14 12:54, Gary Gapinski wrote:
> Possibly of interest: Mozilla Firefox displays the IDN name in the URL
> bar; Google Chrome displays only Punycode. See also
> https://bugzilla.mozilla.org/show_bug.cgi?id=722299.

The Chrome team are hoping to implement the same algorithm we have
pioneered:
https://code.google.com/p/chromium/issues/detail?id=336973

Gerv

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 13 Feb 2014 15:36:42 -0800

And, with many thanks to Rob, https://www.éxample.org/ (also known as https://www.xn--xample-9ua.org/) should now let you test with a cert whose CN has éxample.org, not the Punycode.

--Paul Hoffman

---

From: "Ryan Sleevi" <[email-masked]>
Date: Thu, 13 Feb 2014 20:16:01 -0800

On Thu, February 13, 2014 3:36 pm, Paul Hoffman wrote:
>  And, with many thanks to Rob, https://www.éxample.org/ (also known as
>  https://www.xn--xample-9ua.org/) should now let you test with a cert whose
>  CN has éxample.org, not the Punycode.
>
>  --Paul Hoffman
>  _______________________________________________
>  wpkops mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/wpkops
>

Unfortunately, it still includes the Punycode in the SAN, as would be
expected of a BR-conforming CN. The result of this is every (browser)
implementation I know of will ignore the CN, fall back to the SAN, and
thus perform punycode matching the same as in the .com case.

I only highlight this because in the absence of the SAN, CryptoAPI (aka
IE) will take the Punycode'd input domain and expand it to its U-Label
form, then compare that with the Common Name. I'm not aware of any other
implementations that perform this step (either punycoding the CN or taking
the A-Labels and converting to U-Labels)

For those with your Crypt32 PDBs (from the Microsoft symbol store),
debuggers handy, and perverse interests, look for calls to the function
CompareSSLDNStoCommonName, which will promote Punycode'd names into the
Unicode form ( I_ConvertIdnHostNameToAsciiOrUnicode ), before doing a
string comparison ( CompareStringW ).

Chrome on Windows used to do the same, by virtue of relying on CryptoAPI,
although the name checks in Windows have since been disabled in favour of
an internal implementation that is normalized across all Chrome platforms
(
https://code.google.com/p/chromium/codesearch#chromium/src/net/cert/x509_certificate.cc&rcl=1392294813&l=503
)

It would take a non-BR cert to cover this case.