I understand that the browser handles socket connections and that the SSL handshake occurs prior to any party sending data. However in an XMLHTTPRequest, I'd like to know if its possible to get these details as some sort of response code etc?
Of course, it could have also been left out for security reasons...I'm not creative enough to come up with one at the moment, but I'm sure there's an exploit to be had there as well.
The certificate isn't part of the DOM, so no, this won't be possible. Sorry!
Nope, not possible.
However, as mentioned on this Information Security post, this is not really a desirable option for these browsers to implement, as it would allow a situation where a website developer could write code to mistakenly trust user side credentials.
Office Worker Bob is on one side of the great firewall of Mega Corp., IT Mallory is in charge of the firewall passing traffic in and out of the company locally, and Web Host Alice's awesome website is out on the WWW.
(Note: I did not address the case where you're running JS server-side, then it would depend on what program you're using to run your JS code.)
XMLHTTPRequestJS object; moreover quite possibly the strongest argument to be made against sharing PKI details with
XMLHTTPRequestis as follows:
XMLHTTPRequest object reside on the HTTP(app layer) side of that line, while the whole certificate exchange process resides on the S(trans/sec layer) side of that line. In order to keep the security side atomic(hot-swappable) its internal workings cannot be exposed across the line to the application side; because there may come a day when the transport/security layer no longer uses PKI certificates to facilitate its secure communication service, and when that day comes no one would need to rewrite any existing JS code that was relying on details contained within those certificates to deal with the propagation wave caused by the www community slowly adopting their favorite flavor of any new security layer.
That being said, the security side does appear to also be doing legal entity vetting --at least in some cases like EV certificates--, and it is IMO a short coming of RFC7230 section 2.7.2 that it does not redefine the
authority of the
https-URI to include an optional
legalentity that the security layer would use when verifying the url it is communicating with is not only the proper end point but also currently under control of the intended business relation.
authority = [ userinfo "@" ] host [ "#" legalentity ] [ ":" port ] legalentity = *( unreserved / pct-encoded / sub-delims )
©2020 All rights reserved.