How can I make Chromium send the new WebSocket handshake? - google-chrome

I came across this code change in Chromium. It says Chromium now supports both handshake versions, which the code seems to confirm. I mean the second version at Wikipedia (draft-ietf-hybi-thewebsocketprotocol-06).
However, when I connect to my server, the only thing I obtain is the old version, i.e. including these headers:
Sec-WebSocket-Key1: 4 #1 46546xW%0l 1 5
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
but not the new version which would be a request containing:
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
What am I missing here? I downloaded the latest nightly build and it has been included more than two weeks ago, so that cannot be the cause I guess.
How can I make a WebSocket send the new handshake version?

The code link you posted is for the server-side of the handshake (there is a few places this will likely be used in Chrome such as remote debugging and as a proxy for extensions).
If you really want use the new HyBi-07 protocol version you can try using this branch of web-socket-js that I made. Once Chrome switch to the new protocol, web-socket-js will switch by default also. In order to make web-socket-js work in a browser that already has WebSockets support you will need make some minor tweaks to it to use a different object name instead of WebSocket.
I expect Chrome/WebKit will add the new protocol before long. Note that the API changes to add binary support have only recent been decided so Chrome the new protocol may be added before the API fully supports the new functionality enabled by the protocol.

The only browser I know of that implements the 07 protocol is this build of FF4:
http://www.ducksong.com/misc/websockets-builds/ws-07/

Related

ERR_HTTP2_PROTOCOL_ERROR in Chrome. Works in Firefox [duplicate]

I'm currently working on a website, which triggers a net::ERR_HTTP2_PROTOCOL_ERROR 200 error on Google Chrome. I'm not sure exactly what can provoke this error, I just noticed it pops out only when accessing the website in HTTPS. I can't be 100% sure it is related, but it looks like it prevents JavaScript to be executed properly.
For instance, the following scenario happens :
I'm accessing the website in HTTPS
My Twitter feed integrated via https://publish.twitter.com isn't loaded at all
I can notice in the console the ERR_HTTP2_PROTOCOL_ERROR
If I remove the code to load the Twitter feed, the error remains
If I access the website in HTTP, the Twitter feed appears and the error disappears
Google Chrome is the only web browser triggering the error: it works well on both Edge and Firefox.
(NB: I tried with Safari, and I have a similar kcferrordomaincfnetwork 303 error)
I was wondering if it could be related to the header returned by the server since there is this '200' mention in the error, and a 404 / 500 page isn't triggering anything.
Thing is the error isn't documented at all. Google search gives me very few results. Moreover, I noticed it appears on very recent Google Chrome releases; the error doesn't pop on v.64.X, but it does on v.75+ (regardless of the OS; I'm working on Mac tho).
Might be related to Website OK on Firefox but not on Safari (kCFErrorDomainCFNetwork error 303) neither Chrome (net::ERR_SPDY_PROTOCOL_ERROR)
Findings from further investigations are the following:
error doesn't pop on the exact same page if server returns 404 instead of 2XX
error doesn't pop on local with a HTTPS certificate
error pops on a different server (both are OVH's), which uses a different certificate
error pops no matter what PHP version is used, from 5.6 to 7.3 (framework used : Cakephp 2.10)
As requested, below is the returned header for the failing ressource, which is the whole web page. Even if the error is triggering on each page having a HTTP header 200, those pages are always loading on client's browser, but sometimes an element is missing (in my exemple, the external Twitter feed). Every other asset on the Network tab has a success return, except the whole document itself.
Google Chrome header (with error):
Firefox header (without error):
A curl --head --http2 request in console returns the following success:
HTTP/2 200
date: Fri, 04 Oct 2019 08:04:51 GMT
content-type: text/html; charset=UTF-8
content-length: 127089
set-cookie: SERVERID31396=2341116; path=/; max-age=900
server: Apache
x-powered-by: PHP/7.2
set-cookie: xxxxx=0919c5563fc87d601ab99e2f85d4217d; expires=Fri, 04-Oct-2019 12:04:51 GMT; Max-Age=14400; path=/; secure; HttpOnly
vary: Accept-Encoding
Trying to go deeper with the chrome://net-export/ and https://netlog-viewer.appspot.com tools is telling me the request ends with a RST_STREAM :
t=123354 [st=5170] HTTP2_SESSION_RECV_RST_STREAM
--> error_code = "2 (INTERNAL_ERROR)"
--> stream_id = 1
For what I read in this other post, "In HTTP/2, if the client wants to abort the request, it sends a RST_STREAM. When the server receives a RST_STREAM, it will stop sending DATA frames to the client, thereby stopping the response (or the download). The connection is still usable for other requests, and requests/responses that were concurrent with the one that has been aborted may continue to progress.
[...]
It is possible that by the time the RST_STREAM travels from the client to the server, the whole content of the request is in transit and will arrive to the client, which will discard it. However, for large response contents, sending a RST_STREAM may have a good chance to arrive to the server before the whole response content is sent, and therefore will save bandwidth."
The described behavior is the same as the one I can observe. But that would mean the browser is the culprit, and then I wouldn't understand why it happens on two identical pages with one having a 200 header and the other a 404 (same goes if I disable JS).
In my case it was - no disk space left on the web server.
For several weeks I was also annoyed by this "bug":
net :: ERR_HTTP2_PROTOCOL_ERROR 200
In my case, it occurred on images generated by PHP.
It was at header() level, and on this one in particular:
header ('Content-Length:'. Filesize($cache_file));
It did obviously not return the exact size, so I deleted it and everything works fine now.
So Chrome checks the accuracy of the data transmitted via the headers, and if it does not correspond, it fails.
EDIT
I found why content-length via filesize was being miscalculated: the GZIP compression is active on the PHP files, so excluding the file in question will fix the problem. Put this code in the .htaccess:
SetEnvIfNoCase Request_URI ^ / thumb.php no-gzip -vary
It works and we keep the header Content-length.
I am finally able to solve this error after researching some things I thought is causing the error for 24 errors. I visited all the pages across the web. And I am happy to say that I have found the solution.
If you are using NGINX, then set gzip to off and add proxy_max_temp_file_size 0; in the server block like I have shown below.
server {
...
...
gzip off;
proxy_max_temp_file_size 0;
location / {
proxy_pass http://127.0.0.1:3000/;
....
Why? Because what actually happening was all the contents were being compressed twice and we don't want that, right?!
The fix for me was setting minBytesPerSecond in IIS to 0. This setting can be found in system.applicationHost/webLimits in IIS's Configuration Editor. By default it's set to 240.
It turns out that some web servers will cut the connection to a client if the server's data throughput to the client passes below a certain limit. This is to protect against "slow drip" denial of service attacks. However, this limit can also be triggered in cases where an innocent user requests many resources all at once (such as lots of images on a single page), and the server is forced to ration the bandwidth for each request so much that it causes one or more requests to drop below the throughput limit, which causes the server to cut the connection and shows up as net::ERR_HTTP2_PROTOCOL_ERROR in Chrome.
For example, if you request 11 GIF images all at once, and each individual GIF is 10 megabytes (11 * 10 = 110 megabytes total), and the server is only able to serve at 100 megabytes per second (per thread), the server will have to slow the throughput on the last GIF image until the first 10 are finished. If the throughput on that last GIF is slowed so much that it drops below the minBytesPerSecond limit, it will cut the connection.
I was able to resolve this by following these steps:
I used Chrome's Network Log Export tool at chrome://net-export/ to see exactly what was behind the ERR_HTTP2_PROTOCOL_ERROR error. I started the log, reproduced the error, and stopped the log.
I imported the log into the log viewer at https://netlog-viewer.appspot.com/#import, and saw an interesting event titled HTTP2_SESSION_RECV_RST_STREAM, with error code 8 (CANCEL).
I did some Googling on the term "RST_STREAM" (which appears to be an abbreviated form of "reset stream") and found a discussion between some people talking about an IIS setting called minBytesPerSecond (discussion here: https://social.msdn.microsoft.com/Forums/en-US/aeb01c46-bcdf-40ed-a417-8a3558221137). I also found another discussion where there was some debate about whether minBytesPerSecond was intended to protect against slow HTTP DoS (slow drip) attacks (discussion here: IIS 8.5 low minBytesPerSecond not working against slow HTTP POST). In any case, I learned that IIS uses minBytesPerSecond to determine whether to cancel a connection if it cannot sustain the minimum throughput. This is relevant in cases where a single user makes many requests to a large resource, and each new connection ends up starving all the other unfinished ones, to the point where some may fall below the minBytesPerSecond threshold.
To confirm that the server was canceling requests due to a minBytesPerSecond error, I checked my server's HTTPERR log at c:\windows\system32\logfiles\httperr. Sure enough, I opened the file and did a text search for "MinBytesPerSecond" and there were tons of entries for it.
So after I changed the minBytesPerSecond to 0, I was no longer able to reproduce the ERR_HTTP2_PROTOCOL_ERROR error. So, it appears that the ERR_HTTP2_PROTOCOL_ERROR error was being caused by my server (IIS) canceling the request because the throughput rate from my server fell below the minBytesPerSecond threshold.
So for all you reading this right now, if you're not using IIS, maybe there is a similar setting related to minimum throughput rate you can play with to see if it gets rid of the ERR_HTTP2_PROTOCOL_ERROR error.
I experienced a similar problem, I was getting ERR_HTTP2_PROTOCOL_ERROR on one of the HTTP GET requests.
I noticed that the Chrome update was pending, so I updated the Chrome browser to the latest version and the error was gone next time when I relaunched the browser.
I encountered this because the http2 server closed the connection when sending a big response to the Chrome.
Why?
Because it is just a setting of the http2 server, named WriteTimeout.
I had this problem when having a Nginx server that exposing the node-js application to the external world. The Nginx made the file (css, js, ...) compressed with gzip and with Chrome it looked like the same.
The problem solved when we found that the node-js server is also compressed the content with gzip. In someway, this double compressing leading to this problem. Canceling node-js compression solved the issue.
I didn't figure out what exactly was happening, but I found a solution.
The CDN feature of OVH was the culprit. I had it installed on my host service but disabled for my domain because I didn't need it.
Somehow, when I enable it, everything works.
I think it forces Apache to use the HTTP2 protocol, but what I don't understand is that there indeed was an HTTP2 mention in each of my headers, which I presume means the server was answering using the right protocol.
So the solution for my very particular case was to enable the CDN option on all concerned domains.
If anyone understands better what could have happened here, feel free to share explanations.
I faced this error several times and, it was due to transferring large resources(larger than 3MB) from server to client.
This error is currently being fixed: https://chromium-review.googlesource.com/c/chromium/src/+/2001234
But it helped me, changing nginx settings:
turning on gzip;
add_header 'Cache-Control' 'no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0';
expires off;
In my case, Nginx acts as a reverse proxy for Node.js application.
We experienced this problem on pages with long Base64 strings. The problem occurs because we use CloudFlare.
Details: https://community.cloudflare.com/t/err-http2-protocol-error/119619.
Key section from the forum post:
After further testing on Incognito tabs on multiple browsers, then
doing the changes on the code from a BASE64 to a real .png image, the
issue never happened again, in ANY browser. The .png had around 500kb
before becoming a base64,so CloudFlare has issues with huge lines of
text on same line (since base64 is a long string) as a proxy between
the domain and the heroku. As mentioned before, directly hitting
Heroku url also never happened the issue.
The temporary hack is to disable HTTP/2 on CloudFlare.
Hope someone else can produce a better solution that doesn't require disabling HTTP/2 on CloudFlare.
In our case, the reason was invalid header.
As mentioned in Edit 4:
take the logs
in the viewer choose Events
chose HTTP2_SESSION
Look for something similar:
HTTP2_SESSION_RECV_INVALID_HEADER
--> error = "Invalid character in header name."
--> header_name = "charset=utf-8"
By default nginx limits upload size to 1MB.
With client_max_body_size you can set your own limit, as in
location /uploads {
...
client_max_body_size 100M;
}
You can set this setting also on the http or server block instead (See here).
This fixed my issue with net::ERR_HTTP2_PROTOCOL_ERROR
Just posting here to let people know that ERR_HTTP2_PROTOCOL_ERROR in Chrome can also be caused by an unexpected response to a CORS request.
In our case, the OPTIONS request was successful, but the following PUT that should upload an image to our infrastructure was denied with a 410 (because of a missing configuration allowing uploads) resulting in Chrome issuing a ERR_HTTP2_PROTOCOL_ERROR.
When checking in Firefox, the error message was much more helpful:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.[...] (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 410.
My recommendation would be to check an alternative browser in this case.
I'm not convinced this was the issue but through cPanel I'd noticed the PHP version was on 5.6 and changing it to 7.3 seemed to fix it. This was for a WordPress site. I noticed I could access images and generic PHP files but loading WordPress itself caused the error.
Seems like many issues may cause ERR_HTTP2_PROTOCOL_ERROR: in my case it was a minor syntax error in a php-generated header, Content-Type : text/plain . You might notice the space before the colon... that was it. Works no problem when the colon is right next to the header name like Content-Type: text/plain. Only took a million hours to figure out... The error happens with Chrome only, Firefox loaded the object without complaint.
If simply restarting e.g., Chrome Canary, with a fresh profile fixes the problem, then one surely
is the "victim" of a failed Chrome Variation! Yes, there are ways to opt out of being a Guinea pig in Chrome's field testing.
In my case
header params can not set null or empty string
{
'Authorization': Authorization //Authorization can't use null or ''
}
I got the same issue (asp, c# - HttpPostedFileBase) when posting a file that was larger than 1MB (even though application doesn't have any limitation for file size), for me the simplification of model class helped. If you got this issue, try to remove some parts of the model, and see if it will help in any way. Sounds strange, but worked for me.
I have been experiencing this problem for the last week now as I've been trying to send DELETE requests to my PHP server through AJAX. I recently upgraded my hosting plan where I now have an SSL Certificate on my host which stores the PHP and JS files. Since adding an SSL Certificate I no longer experience this issue. Hoping this helps with this strange error.
I also faced this error and I believe there can be multiple reasons behind it. Mine was, ARR was getting timed-out.
In my case, browser was making a request to a reverse proxy site where I have set my redirection rules and that proxy site is eventually requesting the actual site. Now for huge data it was taking more than 2 minutes 5 seconds and Application Request Routing timeout for my server was set to 2 minutes. I fixed this by increasing the ARR timeout by below steps:
1. Go to IIS
2. Click on server name
3. Click on Application Request Routing Cache in the middle pane
4. Click Server Proxy settings in right pane
5. Increase the timeout
6. Click Apply
My team saw this on a single javascript file we were serving up. Every other file worked fine. We switched from http2 back to http1.1 and then either net::ERR_INCOMPLETE_CHUNKED_ENCODING or ERR_CONTENT_LENGTH_MISMATCH. We ultimately discovered that there was a corporate filter (Trustwave) that was erroneously detecting an "infoleak" (we suspect it detected something in our file/filename that resembled a social security number). Getting corporate to tweak this filter resolved our issues.
For my situation this error was caused by having circular references in json sent from the server when using an ORM for parent/child relationships. So the quick and easy solution was
JsonConvert.SerializeObject(myObject, new JsonSerializerSettings { ReferenceLoopHandling = ReferenceLoopHandling.Ignore })
The better solution is to create DTOs that do not contain the references on both sides (parent/child).
I had another case that caused an ERR_HTTP2_PROTOCOL_ERROR that hasn't been mentioned here yet. I had created a cross reference in IOC (Unity), where I had class A referencing class B (through a couple of layers), and class B referencing class A. Bad design on my part really. But I created a new interface/class for the method in class A that I was calling from class B, and that cleared it up.
I hit this issue working with Server Sent Events. The problem was solved when I noticed that the domain name I used to initiate the connection included a trailing slash, e.g. https://foo.bar.bam/ failed with ERR_HTTP_PROTOCOL_ERROR while https://foo.bar.bam worked.
In my case (nginx on windows proxying an app while serving static assets on its own) page was showing multiple assets including 14 bigger pictures; those errors were shown for about 5 of those images exactly after 60 seconds; in my case it was a default send_timeout of 60s making those image requests fail; increasing the send_timeout made it work
I am not sure what is causing nginx on windows to serve those files so slow - it is only 11.5MB of resources which takes nginx almost 2 minutes to serve but I guess it is subject for another thread
In my case, the problem was that Bitdefender provided me with a local ssl certificate, when the website was still without a certificate.
When I disabled Bitdefender and reloaded the page, the actual valid server ssl certificate was loaded, and the ERR_HTTP2_PROTOCOL_ERROR was gone.
In my case, it was WordPress that now requires PHP 7.4 and I was running 7.2.
As soon as I updated, the errors disappeared.
Happened again and this time it was the ad-blocker that didn't like the name of my images (yt.png, ig.png, url.png). I added a prefix and all loaded ok.
In my case, the time on my computer (browser client) was out of date, synced it using settings in windows, and then the error got away
I had line breaks in my Content-Security-Policy in my nginx.conf that produced this error when used in an docker container running in Kube in GCP (serving angular but I doubt that matters).
Putting them all back on the same line and the problem went away.
A curl -v helped diagnose.
http2 error: Invalid HTTP header field was received: frame type: 1, stream: 1, name: [content-security-policy], value: [script-src 'unsafe-inline' 'self....
It was much easier to edit on separate lines but never again!

How to get the Request Headers using the Chrome Devtool Protocol

The new chrome versions 72+ does not send the requestHeaders .
there was a solution:
DevTools Protocol network inspection is located quite high in the network stack. This architecture doesn't let us collect all the headers that are added to the requests. So the ones we report in Network.requestWillBeSent and Network.requestIntercepted are not complete; this will stay like this for the foreseeable future.
There are a few ways to get real request headers:
• the crude one is to use proxy
• the more elegant one is to rely on Network.responseReceived DevTools protocol event. The actual headers are reported there as requestHeaders field in the Network.Response.
This worked fine with the old chromes but not with the last versions. here is a small summery I made for the versions a coulded test
a solution for chrome v67 was to add this flags to disable Site Isolation :
chrome --disable-site-isolation-trials --disable-features=IsolateOrigins,site-per-process --disable-web-security
Now all of this does not work with the last chrome v73
maybe it is caused by this:
Issue 932674: v72 broke devtools request interception inside cross-domain iframes
you can use Fetch protocol domain that is available since m74
the solution gaven does not work neither, the Fetch.requestPaused does not contain the request headers...
I found some info that maybe causes that:
DevTools: do not expose raw headers for cross-origin requests
DevTools: do not report raw headers and cookies for protected subresources. In case subresource request's site needs to have its document protected, don't send raw headers and cookies into the frame's renderer.
or it is caused when it is an HTTP/2 server?
Does the HTTP/2 header frame factor into a response’s encodedDataLength? (Remote Debugging Protocol)
...headersText is undefined for HTTP/2 requests
link
1- How can I get the Request Headers using the Chrome Devtool Protocol with chrome v73+?
2- Can a webextension solve that?
3- Is there another way which will be stable and last longuer? like tshark+sslkeylogfile which I'm attempting to avoid. thank you

Incomplete Implementation of CTAP2 (FIDO2) protocol in Chrome?

I've been investigating the implementation of CTAP2 protocol with Google Chrome (protocol between Fido Authenticator and Fido Client (e.g. Chrome)), which should be supported in Chrome since version 69.
So I dumped the chrome request to the authenticator in two cases:
1. U2F (CTAP1) with yubico demo website.
Here everything goes as expected and chrome follows the CTAP1 protocol.
2. FIDO2/Webauthn (CTAP2) with webauthn.org
And the browser has a strange behaviour:
It starts by following the CTAP2 protocol by sending a AuthenticatorGetInfoRequest
The Authenticator replies with AuthenticatorGetInfoResponse
But then Chrome switches to the CTAP1 protocol by sending a Registration Request Message (U2F_REGISTER)
Is it a problem with Chrome implementation: CTAP2 is not enabled entirely yet (it seems to be implemented in Chromium sources)?
Or is the problem coming from the authenticator: sending a response that makes Chrome switch to CTAP1?
Or something else entirely?
In AuthenticatorGetInfoRequest, the authenticator must respond with a string list of the supported versions among "U2F_V2" and "FIDO_2_0". Note also in case of NFC or CCID, a "FIDO_2_0" (CTAP2) only authenticator shall anwser directly "FIDO_2_0" on the SELECT command. I don't know about HID and BLE.
So maybe your authenticator is listing "U2F_V2" in the protocol versions list in AuthenticatorGetInfoRequest.
I also imagine the Chrome code base about this was moving fast and can be partial or not strict. To my tests in early 2020, the Chrome CTAP capabilities seem now stable and compliant.

https from as3 air project to webservice using as3httpclientlib

I am trying to change webservice implementation I have done over to use HTTPS.
I have been using the as3httpclientlib (https://code.google.com/p/as3httpclientlib/).
When I use a non-ssl endpoint it works as expected.
However when I use an SSL endpoint and version 1.3 as3crypt from the downloads page (https://code.google.com/p/as3crypto/downloads/list) or the included as3crypto-1_3_patched.swc I get the following:
I DONT KNOW HOW TO HANDLE DER stuff of TYPE 22
I DONT KNOW HOW TO HANDLE DER stuff of TYPE 22
I DONT KNOW HOW TO HANDLE DER stuff of TYPE 22
I DONT KNOW HOW TO HANDLE DER stuff of TYPE 22
I DONT KNOW HOW TO HANDLE DER stuff of TYPE 12
I DONT KNOW HOW TO HANDLE DER stuff of TYPE 22
I DONT KNOW HOW TO HANDLE DER stuff of TYPE 22
I DONT KNOW HOW TO HANDLE DER stuff of TYPE 22
I DONT KNOW HOW TO HANDLE DER stuff of TYPE 22
[Fault] exception, information=TypeError: Error #1009: Cannot access a property or method of a null object reference.
With the traces originating from Line 123 of DER.as
https://code.google.com/p/as3crypto/source/browse/trunk/as3crypto/src/com/hurlant/util/der/DER.as?r=7
and the error from line 225 of X509Certificate.as
https://code.google.com/p/as3crypto/source/browse/trunk/as3crypto/src/com/hurlant/crypto/cert/X509Certificate.as?spec=svn28&r=7
When I use the latest version of as3crypt https://code.google.com/p/as3crypto/source/detail?r=28 I get
[Fault] exception, information=Error: couldn't parse DER stream.
Thrown from line 23 of https://code.google.com/p/as3crypto/source/browse/trunk/as3crypto/src/com/hurlant/util/asn1/type/SetType.as
The webservice I am trying to access is on azurewebsites, so will be using the *.azurewebsites.net certificate.
I am also using the ASC2 compiler, this caused a couple of bugs which I had to fix in the crypto project including changing if (hex.length&1==1) hex="0"+hex; to if ((hex.length&1)==1) hex="0"+hex; which I found posted here com.hurlant.util.hex syntax error on air sdk 3.5
I am starting to think it may be something related to the way SSL is done on Azure websites, since when I strip back the request completely, I still get the same error, however pointing to https://www.google.com, I get no error.
They state on their website:
HTTPS doesn't always work. There are some minor bugs with the
as3crypto library, so for example https at yahoo and yahoo owned
domains (like delicious) don't currently work.
I had a look through the list of issues for as3crypt, and was wondering whether one of these contained a fix: https://code.google.com/p/as3crypto/issues/list
Does anyone know why I am getting these errors (what it is that azure are doing differently with their certificate (could it be the wildcard?)) and how I can fix it? Is there a maintained version of as3crypto that works? Or is there a better way for consuming https webservices from Air mobile apps?
****UPDATE****
I tried using the patched version of as3crypto but still no joy. The following is a copy of my stack trace when it errors. Does seem to be an error parsing the certificate?
I also had a look into changing over to SecureSocket but unfortunately it is not supported on iOS.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/SecureSocket.html
AIR profile support: This feature is supported on all desktop
operating systems, but is not supported on all AIR for TV devices. On
mobile devices, it is supported on Android, but not on iOS. You can
test for support at run time using the SecureSocket.isSupported
property.
TO RECREATE:
Make a get request to any https subdomain of azurewebsites.net.
ie the following code will reproduce:
var client:HttpClient = new HttpClient();
client.get(new URI("https://httpstest.azurewebsites.net"));
I have the same issue with DER decoing, and fix from this issue helped me:
http://code.google.com/p/as3crypto/issues/detail?id=39
What about:
Or is there a better way for consuming https webservices from Air mobile apps?
You can try to substitute TLSSocket from as3crypto with Flash native SecureSocket in the as3httpclient, I think it shouldn't be too difficult to do. In my project I tryed to use both SecureSoket and TLSSocket and stood on TLSSocket because SecureSoket requires FP 11 and doesn't work with self-signed certificates that we use on test server, but SecureSoket also works fine and has shown even better performance that TLSSocket. You also can grab already patched version of as3crypto from my github (https://github.com/fsbmain/as3public) :)
If you still have problems, please provide endpoint of your webservice so I'll be able test it.
UPD:
I were able to reproduce your issue and tested certificate parsing with my patched as3crypto lib (it still allows to go deeper through the parsing), I also tested parsing of the same certificate but downloaded with the browser - the same result in both cases (as on your screenshot), so the conclusion is that TLSSocket loads correct and full bytes of certificate but fails to parse it. I tried to fix the parsing but it requires deeper dive into the as3crypto DER format implementation. So I'm afraid the only way to use as3httpclient is to fix DER parsing.
BTW why doesn't standard URLLoader fit you?
The as3crypto.swc file here: http://www.igniterealtime.org/downloads/download-landing.jsp?file=xiff/xiff_3_1_0.zip solved my issue.
as3crypto.swc is inside the libs folder, after extracting.

Chrome extension to listen and capture streaming audio

Is it possible for a Chrome extension to listen for streaming audio from any of the browser's tabs? I would like to capture the streaming audio data and then analyse it.
Thanks
You could try 3 ways, neither one does provide 100% guarantee to meet your needs.
Before going into more detailed descriptions, I must note that Chrome extensions do not provide convenient tools for working on per connection level - sufficiently low level, required for stream capturing. This is by design. This is why the 1-st way is:
To look at other browsers, for example Firefox, which provides low-level APIs for connections. They are already known to be used by similar extensions. You may have a look at MediaStealer. If you do not have a specific requirement to build your system on Chrome, you should possibly move to Firefox.
You can develop a Chrome extension, which intercepts HTTP-requests by means of webRequest API, analyses their headers and extracts media urls (such as containing audio/mpeg MIME-type, for example, in HTTP-headers). Just for a quick example of code you make look at the following SO question - How to change response header in Chrome. Having the url you may force appropriate media download as a file. It will land in default downloads folder and may have unfriendly name. (I made such an extension, but I do not have requirements for further processing). If you need to further process such files, it can be a challenge to monitor them in the folder, and run additional analysis in a separate program.
You may have a look at NPAPI plugins in general, and their streaming APIs in particular. I can imagine that you create a plugin registered for, again, audio/mpeg MIME-type, and receives the data via NPP_NewStream, NPP_WriteReady and NPP_Write methods. The plugin can be wrapped into a Chrome extension. Though I made NPAPI plugins, I never used this API, and I'm not sure it will work as expected. Nethertheless, I'm mentioning this possibility here for completenees. This method requires some coding other than web-coding, meaning C/C++. NB. NPAPI plugins are deprecated and not supported in Chrome since September 2015.
Taking into account that you have some external (to the extension) "fingerprinting service" in mind, which sounds like an intelligent data processing, you may be interested in building all the system out of a browser. For example, you could, possibly, involve a HTTP-proxy, saving media from passing traffic.
If you're writing a Chrome extension, you can use the Chrome tabCapture API to record audio.
chrome.tabCapture.capture({audio: true}, function(stream) {
var recorder = new MediaRecorder(stream);
[...]
});
The rest is left as an exercise to the reader; MDN has more documentation on how to use MediaRecorder.
When this question was asked in 2013, neither chrome.tabCapture nor MediaRecorder existed.
Mac OSX solution using soundflower: http://rogueamoeba.com/freebies/soundflower/
After installing soundflower it should appear as a separate audio device in the sound preferences (apple > system preferences > sound). Divert the computer's audio to the 2ch option (stereo, 16ch is surround), then inside a DAW, such as 'audacity', set the audio input as soundflower. Now the sound should be channeled to your DAW ready for recording.
Note: having diverted the audio from the internal speakers to soundflower you will only be able to hear the audio if the 'soundflowerbed' app is actually open. You know it's open if there's a 8 legged blob in the top right task bar. Clicking this icon gives you the sound flower options.
My privoxy has the following log:
2013-08-28 18:25:27.953 00002f44 Request: api.audioaddict.com/v1/di/listener_sessions.jsonp?_method=POST&callback=_AudioAddict_WP_ListenerSession_create&listener_session%5Bid%5D=null&listener_session%5Bis_premium%5D=false&listener_session%5Bmember_id%5D=null&listener_session%5Bdevice_id%5D=6&listener_session%5Bchannel_id%5D=178&listener_session%5Bstream_set_key%5D=webplayer&_=1377699927926
2013-08-28 18:25:27.969 0000268c Request: api.audioaddict.com/v1/ping.jsonp?callback=_AudioAddict_WP_Ping__ping&_=1377699927928
2013-08-28 18:25:27.985 00002d48 Request: api.audioaddict.com/v1/di/track_history/channel/178.jsonp?callback=_AudioAddict_TrackHistory_Channel&_=1377699927942
2013-08-28 18:25:54.080 00003360 Request: pub7.di.fm/di_progressivepsy_aac?type=.flv
So I got the stream url and record it:
D:\Profiles\user\temp>wget pub7.di.fm/di_progressivepsy_aac?type=.flv
--18:26:32-- http://pub7.di.fm/di_progressivepsy_aac?type=.flv
=> `di_progressivepsy_aac#type=.flv'
Resolving pub7.di.fm... done.
Connecting to pub7.di.fm[67.221.255.50]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [video/x-flv]
[ <=> ] 1,234,151 8.96K/s
I got the file that can be reproduced in any multimedia pleer.