I have a web application in my local WAMP server, which is self signed SSL enabled. that made my app url as
https://myipaddress:port/demoapp/index.html
When I ping the above url in WeChat chat window and click on the link, it is not opening my demoapp home page but just blank page. When I paste same link as with http as http://myipaddress:port/demoapp/index.html. WeChat browser is opening my demoapp homepage without any issues?
Any clues how to open https urls from WeChat in app Browser?
Yes WeChat in app browser is not allowing Self Signed certificates unlike Chrome, where it will ask whether to Trust or Block. I tried placing my demoapp in a server, which has valid DigiCert SHA2 CA certificate and it is working in WeChat.
Related
I search everywhere I found 0 information about this specific redirect.
I have app that I need to use "HTTP" to function, recently chrome started to redirect my app to HTTPS automatically, and If I put HTTPS to HTTP code in my app it cause infinite loop.
My app is not on the HSTS preload domain list, my app and server have no redirect code to HTTPS.
Request URL: http://4444.com/z.txt
Request Method: GET
Status Code: 307 Internal Redirect (from disk cache)
Referrer Policy: strict-origin-when-cross-origin
Cross-Origin-Resource-Policy: Cross-Origin
Location: https://4444.com/z.txt
Non-Authoritative-Reason: DNS
This does not happen on any other browser other than chrome.
Does that mean chrome is targeting my host's dns to make sure all website hosted on the DNS is HTTPS?
If yes I think this is very bad move from google as I can't find any announcement by google that they will start forcing https on websites. This could break many non https sites without prior warning.
If not what can I do to fix this issue?
Thanks
I encountered the same problem just like you, and that situation didn't happen all the time, sometimes when I open another window as incognito mode, the redirect disappeared!Sooooo Annoying:(
And I just tried another way, it seemed to work fine with me!
go to : chrome://net-internals/#dns, and click Clear host cache , then refresh your page, the redirect will be gone!
Even if the "Always use secure connections" (chrome://settings/security) is disabled, chrome will still try to use HTTPS if it finds HTTPS records in DNS, as per #dns-https-svcb flag - "Support for HTTPS records in DNS" (chrome://flags/#dns-https-svcb) - which is enabled by default.
This causes the loop leading to the ERR_TOO_MANY_REDIRECTS with Non-Authoritative-Reason: DNS.
Either remove any HTTPS record from the host zone file or disable the aforementioned flag from chrome.
Did you access websites using VPN? VPN server seems able to force http to https
Browser says "Camera Blocked to protect your privacy"
My project include using user camera and when i access application from localhost camera works fine but when accessing through ipaddress, the browser by default blocks the camera and other resource.. how can i allow them for my application.
My application is for an organization who will be accessing the application using ipaddress.
Thank you for reading and your help. :)
type url chrome://flags/#unsafely-treat-insecure-origin-as-secure
Enter url in the textarea
Choose Enabled in the select option
Click image link bellow to see detail
example
Chrome blocks vulnerable features—including camera, location, microphone, etc. on non-secure sites. As of July 2018, with the release of Chrome 68, Chrome starts to mark all HTTP sites as "not secure."
You have three options to unblock these features for your site:
Treat 192.168.10.79 as secure origins by setting chrome://flags/#unsafely-treat-insecure-origin-as-secure. Origins must have their protocol specified, e.g., http://192.168.10.79.
Port forwarding your site address to localhost. Chrome treats localhost as secure origins.
Set up a self-signed certificate for the server.
The problem is because of http protocol. This is not a secure protocol.
Solution
In my scenario I have used https and have got all permissions.
I started to use Fiddler and I want to be able use it to debug https requests.
I read the part "Configuring for HTTPS Capture" in the
following article: http://www.kleinfelter.com/content/using-fiddler-capture-encrypted-traffic-https
So I decided to change the properties of Fiddler to enable also https requests. I checked both "Capture HTTPS CONNECTs" and "Decrypt HTTPS traffic"
Once I clicked the "OK" button my browser blocked any https requests. Therefore, I couldn't enter any sites with personal information such as Facebook or Gmail. The error message that I got from the browser was:
Your connection is not private
Attackers might be trying to steal your information from
www.facebook.com (for example, passwords, messages, or credit cards).
NET::ERR_CERT_AUTHORITY_INVALID
I probably have to change something in the properties of my browser (Chrome) so I'll be able to submit https requests while fiddler is working. I know it may be unsecure, but once I finish using Fiddler, I'll change it back to its default property.
Do you know what I have to change in my browser?
Fiddler uses its own root CA when acting as a MITM proxy to decrypt HTTPS traffic. This CA is not trusted by Windows (which is good, as Fiddler does not have the authority to issue certificates). Fiddler uses this root CA to create certificates on the fly for HTTPS sites you visit enabling it to decrypt content.
The message you are seeing is Chrome warning you that the issuer of the dynamically Fiddler generated certificate is unknown. On most sites, you can bypass this by accepting the warning but some sites employ additional security practices such as Strict Transport Security (HSTS) and certificate pinning where a browser prohibits you from accepting warnings such as these.
To avoid having browsers show a warning, you should add the Fiddler root certificate to your trusted certificates. IE and Chrome share the same certificate store maintained in Windows, while Firefox maintains its own store internally.
To trust Fiddler's Root certificate,
Click the "Export Root Certificate to Desktop" button in your screen print (in newer versios, this is available behind a button titled "Action" on the same dialog).
This exports the Fiddler root certificate to your desktop.
Open the certificate file and click the "Install Certificate" button.
Proceed with the rest of the prompts to add it to your list of trusted root certificates.
References: https://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp and http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/TrustFiddlerRootCert
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.
Alright, this is the case:
I have a website. When not logged in, it is a http connection.
On my homepage I have a link to another site:
www.somesite.com
So far so good, when pressing the link it goes to the site.
But when I log in to my website, I have a secured connection (https).
Now, when I press the same link, it opens https://www.somesite.com although I have the link hardcoded as http in my code. And the somesite.com does not provide a https connection, so the browser is complaining.
How is this possible and how do I get the browser to just follow the hardcoded url?
Many websites support a non-secured (http) connection up to the point of user authentication. At that point, many sites will redirect to a secured (https) authentication mechanism and conduct all subsequent communication with the authenticated user over https.
The site you are accessing is being redirected by the server to the secure connection. That is why when you access the site via your link via http, the server redirects you to the secure site. If you are familiar with the dev tools in your browser, you can probably follow a network trace of the exchange between you and your site and see the redirect at some point in the communication exchange.