Is there some way to tell Chrome or Safari to use HTTP/2 on a specific URL/adress/server?
I mean by changing some setting or such, not by implementing ALPN on the server socket or whatever might be needed. I want to try HTTP/2 on a server socket without waiting till I can have ALPN negotiation to tell the browsers to use HTTP/2.
Clarification: I have HTTP/2 enabled on Chrome (aka SPDY/4 via chrome://flags). It still doesn't probe my (TLS or plaintext) socket for HTTP/2 via Upgrade. I want to force Chrome to either do this, or assume HTTP/2 right off the bat.
Also, I've read that Chrome won't support HTTP/2 over plaintext connections, even though the HTTP/2 standard allows it. But maybe there's some way around that.
HTTP/2 over TLS and HTTP/2 over TCP have been defined as 2 different protocols, identified respectively by h2 and h2c.
Chrome supports h2 only at this time.
If you have a server that implements only h2c, the easiest way to connect Chrome to it is to use a reverse proxy such a nghttpx in HTTP/2 bridge mode in front of your server
As far as I know this is most likely a browser-wide setting.
In chrome you can enable SPDY4, see chrome://flags
As far as safari goes support has been added since version 8.
In the end it's all about the knowing whether or not you speak the same language as the server. If you are using http you can check this by using the Upgrade header. There are some plugins out there you can use with chrome to give you an indication of whether or not the address your visiting supports http/2.
For more info on the http/2 protocol itself you should check out https://http2.github.io/http2-spec/#starting
Related
Chrome has turned on the enable-quic switch ,but when i But when I visit google, it still uses http2 protocol ,how can I use the browser's http3/quic feature?
enable-quic
http2 protocol
Since HTTP/3 is still a relatively new protocol, browser may first use HTTP/1 or HTTP/2 when connecting to a server. The server may advertise support of HTTP/3 for subsequent connections. However, even after several requests, the browser may end up using HTTP/2 and TCP if QUIC handshake is delayed for some reason.
You may find more information here
https://www.smashingmagazine.com/2021/09/http3-practical-deployment-options-part3/
You can try to force Chrome to use QUIC protocol on a specific domain by starting chrome from the command line
chrome --origin-to-force-quic-on=www.example.org:443
I've a locally hosted SPA (Kestral/.Net core). It is using a self signed certificate for HTTPS communication (generated through Server Certificates in windows 10).
It works well with IE11, however when accessed from Google Chrome, shows up error - ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY.
Any clues on what could be done to overcome this?
Troubleshooting done so far:
Custom cipher suites order.
Disabling HTTP2 through windows registry.
To use HTTP/2 you must be using TLSv1.2 and cannot use a number of blacklisted, less secure ciphers. This basically means you must use one of the GCM ciphers like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (though other newer ciphers like TLS_CHACHA20_POLY1305_SHA256 are also support).
If you only have older ciphers configured then Chrome will fallback to HTTP/1.1 or, if that is not available, it will error with that error message.
Adding if it helps anyone digging on same thing, for Kestral setting Protocol Version to http1 looks to be the way to overcome this issue, as Cipher suite doesn't looks to be configurable in kestral at least with .Net core 3.1.
I can't intercept requests made by Chrome version 73.0.3683.86 to my localhost site.
Local host site is running on IIS on http://127.0.0.3:80
Burp proxy lister is default one on 127.0.0.1:8080
Interception rules are default one as well
In my LAN settings, "Bypass proxy server for local addresses" is not enabled
When Interception is turned ON and I reload page in Chrome browser, no request is "caught" by Burp, my local site loads and only the external requests are intercepted, such as loading external scripts from CDN.
Also under "Proxy" > "HTTP History" there is only request to external sites, and all requests to http://127.0.0.3:80 are not recorded.
When I reload same page by Internet Explorer 11, initial GET request is intercepted by Burp, as expected. Also "Proxy" > "HTTP History" shows all the requests to local site http://127.0.0.3:80
What is the problem with the Chrome? Thanks!
Found the solution late yesterday. I am using the Chrome extension ProxySwitchy, but it doesn't matter if you use that or the system proxy configuration. The solution works the same way.
You can solve this problem by adding an entry in /etc/hosts file like below
127.0.0.1 localhost
127.0.0.1 somehostname
Now burp will intercept request from somehostname
Which version of Chrome are you using?
Have you tried using the FoxyProxy Chrome extension?
As a workaround, you could modify the hosts file on your machine.
I experienced the same issue when I upgraded from Opera 58.0 to 60.0. I think that this is Chrome related, because I've also experienced it in all other Chrome browsers. Opera 58 utilizes Chrome 71.0.3578.98. Opera 60 utilizes version Chrome 73.0.3683.103. Something was definitely updated in Chrome between these versions to cause this problem to happen.
You have to subtract the implicit bypass rules defined in Chrome (https://chromium.googlesource.com/chromium/src/+/master/net/docs/proxy.md#Implicit-bypass-rules)
Requests to certain hosts will not be sent through a proxy, and will
instead be sent directly.
We call these the implicit bypass rules. The implicit bypass rules
match URLs whose host portion is either a localhost name or a
link-local IP literal. Essentially it matches:
localhost
*.localhost [::1]
127.0.0.1/8
169.254/16
[FE80::]/10
https://chromium.googlesource.com/chromium/src/+/master/net/docs/proxy.md#Bypass-rule_Subtract-implicit-rules
Whereas regular bypass rules instruct the browser about URLs that
should not use the proxy, Subtract Implicit Rules has the opposite
effect and tells the browser to instead use the proxy.
In order to be able to proxy through the loopback interface, you have to add the entry
<-loopback>
in the list of hosts for which you don't want to a proxy. It is a bit confusing, indeed.
Make sure you haven't enabled socks proxy option, it happened with me too and i found the solution when i disabled the socks proxy option, just make sure it's disabled!
Example:
It helped me
I turned on this settings
I'm trying to inspect the pakets sent over the sctp connection of webrtc datachannels in chrome on my local machine. There isnt really much information which I found about decrypting DTLS-Traffic (e.g. through wireshark). Is there a way to access the certificate generated for the peerconnection? If not, how would one decrypt the traffic by other means? (e.g. some mitm proxy, mostly those are for TLS only though).
the certificate alone won't help, Chrome typically uses DTLS with perfect forward secrecy.
The --disable-webrtc-encryption (see http://peter.sh/experiments/chromium-command-line-switches/) might work in canary.
Is it possible to open a port using Native Client that other browsers can connect to? Like a browser to browser connection?
In general, no. NaCl does not allow programs to open sockets directly (that would be a security problem). It is intended that NaCl/Pepper applications have the same general capabilities as Javascript applications; so something like WebSockets (connection back to the server) would be supported, but not directly opening files or sockets on the client machine. There's some work going on to have a P2P style networking in HTML5 (e.g. http://www.w3.org/TR/2008/WD-html5-20080122/#peer-to-peer) which would likely get Pepper support as well, but I don't know what the status of that is.
The only way to get P2P connection in browser is through WebRTC. If NaCl allows to use WebRTC (though Pepper API or whatever) then the only thing you need besides implementation is broker server that will connect clients with each other. See PeerJS for some info.