On Fri, Jul 10, 2015 at 4:29 PM, Martin Rex <m...@sap.com> wrote:
> Henrik Grubbström wrote:
>> Martin Rex <m...@sap.com> wrote:
>>> The issue here is the (lack of the) TLSv1.2 signature_algorithms extension.
>>>
>>> Windows SChannel appears to treat the absence of this extension
>>> the same as the presence of an extension with (md5,rsa) (sha1,rsa)
>>> (sha1,dsa)
>>>
>>> If you send the TLSv1.2 signature_algorithms extension with the
>>> algorithm matching the signature of the server certificate, e.g.
>>> (sha256,rsa) in the above example, then a TLSv1.2 handshake will succeed.
>>
>> Sounds like it is complying with the TLS v1.2 RFC. Fix your client.
>
>
> Nope, _our_ client is perfectly compliant by _not_ sending TLS extensions.
> SCHannel is violating a MUST requirement, failing to properly process
> a ServerHello without a TLS extension.
>
> https://tools.ietf.org/html/rfc5246#section-7.4.1.2
>
> 7.4.1.2 ClientHello
>
> extensions
> Clients MAY request extended functionality from servers by sending
> data in the extensions field. The actual "Extension" format is
> defined in Section 7.4.1.4.
>
>
> A server MUST accept ClientHello
> messages both with and without the extensions field,
Yes, and section 7.4.1.4.1 says that that means:
| If the client does not send the signature_algorithms extension, the
| server MUST do the following:
|
| - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
| DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
| sent the value {sha1,rsa}.
|
| - If the negotiated key exchange algorithm is one of (DHE_DSS,
| DH_DSS), behave as if the client had sent the value {sha1,dsa}.
|
| - If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
| ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
Which indicates that the server in effect MUST behave as if there was
an implicit signature_algorithms value of
{{sha1,rsa},{sha1,dsa},{sha1,ecdsa}}.
Section 7.4.2 then says that the certificate chain either MUST or
SHOULD (depending on the interpretation of the "behave as if" above)
be validated against the implicit signature_algorithms extension.
--
Henrik Grubbström gru...@grubba.org
Roxen Internet Software AB gru...@roxen.com
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
