7

I played around with a man-in-the-middle proxy tool and connected different smart phones to it. As the proxy uses a self signed certificate the tested smartphone apps did not accept the presented server certificate.

The interesting part (from my perspective) was that different smartphone platforms used totally different messages and strategies for making sure that the TLS connection can not be established.

Some just sent a ALERT message with description bad_certificate(42) or certificate_unknown(46). Other phones just continued the handshake but later the key exchange deterministically failed.

I found especially the last case interesting as it is unclear how the client force the handshake phase to fail and if an adapted server/proxy may still be able to "save" the handshake phase and establish the connection...

Are the actions a client should perform somewhere written down in an RFC for dropping the connection in case an untrusted certificate was detected?

If no, does somebody knows what mechanism is usually used for willfully sabotaging the TLS handshake phase?

Improve this question
1
  • Might be a client optimisation. I don't think there's a standard for this. See section #1 in Tom Leek's answer here: SSL Handshake failed
    – StackzOfZtuff
    CommentedJun 25, 2015 at 17:40

1 Answer 1

Reset to default
-1

X509 certificate validation is covered in RFC 5280.

Look at section 6 (https://www.rfc-editor.org/rfc/rfc5280#section-6)

Conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality
equivalent to the external behavior resulting from this procedure.

Improve this answer
3
  • The connection is as I wrote untrusted, therefore it is clear that the certificate validation fails. Hence I don't understand why you post a link to the X.509 standard. The question is if it is standardized how the SSL/TLS implementation reacts in such a situation. The answer can therefore not be found in the X.509 standard...
    – Robert
    CommentedApr 24, 2016 at 11:14
  • @Robert, I was responding to the second to last scentence, which I assumed was your question. "Are the actions a client should perform somewhere written down in an RFC for dropping the connection in case an untrusted certificate was detected?" - Robert.
    – Daisetsu
    CommentedApr 24, 2016 at 16:28
  • I still not understand how the "Certification Path Validation" should answer this question. It answers the question "when" to drop the connection but it does not answers what actions a client should perform to actually drop the connection.
    – Robert
    CommentedApr 25, 2016 at 8:01

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.