I'm using Advanced REST Client to test external API which requires me to specify
Connection: Keep-Alive. The connection fails (NO RESPONSE) and inspecting Chrome console I noticed Refused to set unsafe header "Connection" followed by net::ERR_INSECURE_RESPONSE
Is there any Chrome settings that allow me to override this? BTW, the API works when I use external tools like APIGee. I've tried Chrome CORS extension (Allow Control Allow Origin) but still unsuccessful.
The issue is that chrome is refusing to load a resource that has an invalid or expired SSL certificate. Even if you could get it to bypass that it would be a bad idea as it would make man in the middle attacks easier in your application.
My suggestion would be (if you trust the server or if it's running locally) to import that certificate to your store so it's trusted in your development environment. If the cert is expired and it's hosted locally look at the documentation on how to change the certificate or to add a self signed one (which you then also would add to your trusted sites)
How to add a self signed very to your store
For Mac
For windows
You'll have to restart chrome for it to see the certs in the store after doing this
Again, be sure you trust these certs origin as they'll be considered trusted as if a legit CA HAD issued them
Related
I'm a front-end developer working on an application where the login/ response put a Session-Cookie on the client. The later request will be authorized since the user "logged in".
Starting from Chrome 80
All cookies without a SameSite attribute will be treated as if they had SameSite=Lax specified. In other words, they will be restricted to first-party only (server and client on the same domain).
If you need third-party cookies (server and client on different domains), then they must be marked with SameSite=None.
Restricted to first-party by default
Set-Cookie: cname=cvalue; SameSite=Lax
Allowed in third-party contexts
Set-Cookie: cname=cvalue; SameSite=None; Secure
For my application, I want the default behavior. My client and server running on the same domain in production. But in development I'm working from localhost (different domain).
Up until now, chrome had special flag under chrome://flags - SameSite by default cookies. I could Enable this flag on my development machine and the login passed. And in production, I didn't need this flag because I wanted the default behavior.
Starting from Chrome 91
The SameSite by default cookies flag was removed. This means that from this version I can't login into my app, without deploying it to production.
Does anybody knows how can I get the Session-Cookie while working from localhost. But still keeping the security of SameSite=Lax. If possible with client only changes, but if needed also with server changes.
Chrome DevTools - SameSite error message
Chrome 80 Flags menu - These flags removed in Chrome 91
Update
I tried to solve this by making the server use SameSite=None (development only).
This causes a different error: Connection isn't secure. This is because when using SameSite=None you are required to add the suffix Secure and of curse use HTTPS connection.
Secure connection has its own problems like having to pay for a Certificate in development.
Workaround: Downgrade Chrome
This is not a solution! just a temporary workaround for anybody like me how got his work halted due to this update.
Uninstall Chrome
Go to "Add or remove programs" and uninstall Chrome. Notice that user data like cookies and saved browser passwords may be lost.
Download Chrome v90 from slimjet.com, or from any other site. Then install Chrome.
Prevent auto-update Chrome, according to this StackOverflow solution: open C:\Program Files (x86)\Google\Update
rename the file GoogleUpdate.exe to GoogleUpdate2.exe.
This will cause Chrome to not find the update package.
Update Flags - Open Chrome and type: chrome://flags
Search #same-site-by-default-cookies and Disable the flag
I have found a way to fix it and share it with everyone :-)
Description appears in the issues section:
Specify SameSite=None and Secure if the cookie should be sent in
cross-site requests. This enables third-party use.
In the Developer Tools section, go to the Application tab, and on the left side to Cookies:
The cookie that you want to share with other domains, mark the Secure
check and in Samesite put None. Update the site tab locally and you
will be able to use the cookies that allow you to send through the
domain of origin
I hope this brightens your day
As of Chrome v107 (Nov 2022)
I had a similar issue, spent a few hours digging, and what I found is that the only solution for Chrome is to make your front-end connection secure, ie https (using a proxy for instance): Link
An alternative solution is to use Firefox and set: about:config > network.cookie.sameSite.noneRequiresSecure=false. This allows SameSite=None; Secure=false
In our case, we are able to also run our server locally on a different port and point our client app to that localhost address for development purposes.
For example, I have the client app running on localhost:1234 and sending requests to a local copy of the server running on localhost:5678. This ensures that cookies are set successfully since the client and server are now "SameSite".
Admittedly, this is perhaps more of a workaround than a solution, but I hope it helps in the short term.
If you want to perform "unsafe" CORS requests (which means performing a POST/PUT/DELETE request) you will need to modify the tomcat conf/context.xml file, to set sameSiteCookies to "none" instead of "lax".
...
<!-- default samesite cookies configuration, for CORS set sameSiteCookies to "none" and configure bundle for HTTPS -->
<CookieProcessor sameSiteCookies="none" />
...
You can set the SameSite attribute manually to "None" + tick "Secure" inside the devtools for development.
That way you would not have to modify your production environment (keep the cookies as SameSite=Lax).
Using: Chrome 67.0.3396.99
Our webserver implements X.509 client authentication. The certificates are offered through the PKCS#11 interface; we connect a smartcard (in this case: Yubikey 4), the browser prompts for the certificate selection and PIN.
We disconnected the smartcard and visited the authenticated domain (say, localhost:8000) to observe the behavior of the webserver (in a local development environment).
The webserver correctly refused to serve the request.
However, Chrome now does never send anymore the certificates while visiting localhost:8000, even if the smartcard is connected.
The following did not resolve the problem:
Clearing all site data through the developer console;
Resettting site preferences to their defaults (through chrome://settings/content/siteDetails?);
Rebuilding the webserver.
Any pointer where I can clear this state from Chrome would be greatly appreciated. As a temporary fix, we run the server at a different port but this is not an option on the long term. As this scenario is very plausible to also happen in production.
We are looking for a way to have Chrome bypass the HSTS requirements for our dev environment.
We are working on a project for https://foo.com.
Within our organizations internal dns we have DNS entries for foo.com.dev which points to our internal dev server which has historically allowed us to reach our dev server via https://foo.com.dev. Secure web requests to this site have always been met with a security warning that we have been able to bypass but in a recent build of Chrome it seems that the ability to bypass the warning has been removed. We can continue to use this method in IE but would like to be able to test Chrome as well.
Additionally, developers have been able to use there own machine names as suffixes. For example a https://foo.com.workstation10
Any suggestions would be very welcome because the prospect of reconfiguring our entire dev environment is not a pleasant one.
To be clear - access to these sites are entirely limited to internal users by both firewall setup and dns configuration.
You can try one of the following options:
Send the Strict-Transport-Security header only for foo.com, and do not specify includeSubDomains.
Make self-signed certificates for foo.com.dev on server and import in on your local device's chrome.
If your target domain is restricted only for internal purpose, you can bypass it just typing badidea in the chrome window. Further details are available here
For more details about HSTS refer HSTS RFC
I'm debugging a local site.
I'm getting the following message in chrome.
Your connection is not private
Attackers might be trying to steal your information from t.buyamerica.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
This is not new, and normally I just click ADVANCED and Procced ...
but lately it just stuck in a loop and display the error message again.
This is a local site therefore the key-pair is indeed invalid, but is there a way to by-pass this issue without installing a proper https for all my local (vagrant based) servers?
NOTE:
The current by-pass for me is to use the same domain as the original site, so that the local site is www.somesite.com, and the actual site is somesite.com
I solved this issue as follow:
In
System Preference -> Network -> WiFi -> Advanced -> Proxies I saw that Secure Http Proxy (HTTPS) is checked and the value for the proxy is localhost:8888
I unchecked the Secure Http Proxy (HTTPS) and it seems to solve the issue.
NOTE: this is a specific MAC issue that apparently caused by a system upgrade (my current version is 10.10.5 (14F2511) Yosemite, MacBook Air (13-inch, Mid 2012))
I never set a proxy server or run any proxy on localhost:8888
You change your local domain something like http://yourdomain.test.
Don't forget the 'http'. And if you're using .dev, change it to .test
I'm using Fiddler2 on Windows to inspect and analyze HTTPS traffic. To make it less cumbersome, I've installed and trusted the Fiddler2 Root certificate. The Fiddler root certificate makes the browsing experience seamless; all the HTTPS sites are still "secured" (ie: the url is still https, and you still see a certificate lock).
But this becomes problematic when I forget to turn off Fiddler, and find myself browsing sites that I want to remain secured, only to find Fiddler still logging my traffic/content.
Is there a Chrome extension that I can install/use that would visible show when the HTTPS connection is secured by a certificate signed by a specific root?
Unfortunately, it doesn't look like such information is available in the chrome.webRequest API, which you would need to get it in a Chrome Extension.
There was previously a request to Provide information about the TLS connections to extensions via the webRequest API, but it was decided not to be implemented.