Quite a while ago I started using an ssh tunnel so I could access services back in the Uk that require a UK client address (such as my library and my doctor).
So I have been using "ssh -fTnN -D 1080 chris#isbd.uk" and setting up the proxy configuration in Firefox to use host 127.0.0.1 and port 1080.
However this didn't work when I was in France last week, I'm not sure when it stopped working (maybe in the last year or so), it now give an error:-
Secure Connection Failed
The connection to the server was reset while the page was loading.
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the web site owners to inform them of this problem.
Has anyone any idea how to fix this? The proxy works for things like curl and lynx so it would seem to be a Firefox issue brought about by security paranoia.
Found this because I had the same problem today - same error message, no useful information - on fedora-34 using Firefox 94.0 and OpenSSH_8.6p1. Also tried GNU Icecat 78.15.0esr same result. Can't test cromium-browser because the system proxy settings need Network Manager, curl with --preproxy sockst5://127.0.0.2:3128 works fine.
Thought my server config was broken but it also applied to all other connections while the browser was set to use the proxy and the system I was worked from other setups where one ff version is in between the two I tested on fedora-33 and the other being version 94.0.1-1 on arch.
that's as far as I'm willing to invest time to debug this for now
Related
In the last week or so (approximately same timeframe as Firefox 75 release), local development of my example application (Rabbit) that uses auth0-spa-js has started failing in Firefox with the below error:
auth0-spa-js must run on a secure origin.
See https://github.com/auth0/auth0-spa-js/blob/master/FAQ.md#why-do-i-get-auth0-spa-js-must-run-on-a-secure-origin
for more information.
Because of some problem I can't quite remember the details of, I've been using rabbit.localhost (with an entry in my hosts to resolve that host to 127.0.0.1) for my local development.
It seems that Firefox trusts "localhost" as a "secure origin", but not "*.localhost" type addresses. The ".localhost" address seems to work fine in Chrome.
The question:
Is there a way to get Firefox to accept a specific "xxx.localhost" as a secure origin?
For the moment, my workaround is to go back to using Chrome for local development.
This is now fixed in version 84:
https://news.ycombinator.com/item?id=25431563
I'm using BurpSuite to intercept the HTTP/HTTPS requests sent when logging in on https://www.nike.com/. I'm trying to achieve this with the following step:
Opening BurpSuite and Firefox
Turning on the proxy intercept
Turning on FoxyProxy on Firefox
Opening the website and trying to logging
These steps usually work for me, but in this case, I'm getting a "we are unable to connect to our servers" error without anything appearing on the intercept tab when trying to logging (I have tried turning off the intercept feature but it still yields the same issue, so I think it might be a proxy and certificate problem).
To clear things up:
I'm running the latest versions of BurpSuite and FireFox.
I have installed and reinstalled the BurpSuite certificate using this guide.
I've tried all of this on my iMac, MacBook and iPhone all of these devices yield the same issue
Here bellow is the error message I'm getting:
Here are my BurpSuite Proxy setting:
(in the Certificate tab I just have Generate CA-signed per-host certificates selected)
I have been using BurpSuite for over 2 years now and it's the first time I'm facing such an issue, any help is appreciated
I have shared my question with the Portswigger support (the team behind BurpSuite) and got the following response:
Hi
Thanks for your message.
We have reproduced the issue in our testing environment.
It looks like Nike.com are performing a fairly sophisticated check to
stop automated tool from accessing parts of their site.
Please let us know if you need any further assistance.
Cheers
Liam Tai-Hogan
PortSwigger Web Security
So I have been using Laravel's Valet feature for my Laravel project for a few weeks no without any problems.
I have updated my Mac OS today and found that my project cannot be reached within Chrome, whats weird is the problem only occurs in Chrome. I can access the site fine in Safari.
I get the follow error on Chrome:
This site can’t be reached myproject.app refused to connect.
The site isn't using SSL so I dont think this is a SSL certificate issue as some people have suggested in other posts I have seen.
I have already checked and all Brew services are running.
Any ideas what this could be?
try change your domain from app to test
valet domain test
Probs a little late on this and you probably found a solution but for others searching:
Little new thing with chrome now, it always wants SSL and is mean about .dev for some reason.
So..
a. Use .test preferably (i see you're already using .app which should work fine!)
b. Use SSL. Simply go to the directory of your application in terminal and enter valet secure to make it use SSL.
c. Check you're not running a proxy or VPN in chrome (spend 2h searching before realising my nordvpn chrome extension automatically connected... thats how I found your question ^^')
otherwise try ps aux | grep in terminal to check if your DNS is working. :)
Are you using a VPN? I had the same problem with ExpreeVPN and I solved it by disabling Only use ExpressVPN DNS servers while connected from Advanced settings. The solution was posted here: https://github.com/laravel/valet/issues/527
I am forced to use a visual-svn-server that is located in our windows domain. The problem is that it is super slow to use with windows client. Weird thing is that the same repository is very fast with linux client. The difference is like 3sec vs 90sec. I know somebody should fix the server, rather than me trying to fix the client, but i have no change of doing that.
So, to debug the problem I did some package capture with wireshark and it seems like windows, when doing 'svn up' (on up to date repository) does quite much ldap-negotiations before actually talking again with the actual svn-server. This takes time. Linux svn client when doing 'svn up' is not doing any ldap calls. The problem is not on my machine, but on all my colleagues windows clients too.
I tried forcing the svn client to 'basic' auth with configuration option http-auth-types (http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html), but it didnt help. I figured that would be basic, no ldap, http-basic-auth. I am able to confirm that the setting is included, since setting it to 'digest' says that authentication method is not available. But even that takes about 60s, so my guess is that its doing the ldap-wacko stuff before trying to do the authentication.
The subversion client i am using is 1.8 serie from tortoise svn official build. I did try also slicksvn client and it did have the same problem. The svn versions shows ra_serf is handling the https requests and my repository is visual-svn server located at https://my_server_intra_dns_name/
When opening the address with browser, its again fast as it should, so problem should not be with dns or similar.
I am linux guy, so i am bit lost with windows, but does anybody have an idea wtf is going on here?
---- edit ----
I had also linux as guest operating system on the windows host, and inside that linux doing svn up was about 3s, compare that to native windows 'svn.exe up' that took over minute !
If a Windows machine has a limited connectivity to the Internet, then you may notice the delay when running Subversion client command's against a remote repository over HTTPS.
Using a traffic analyzer you can notice, that the delay happens when Windows attempts to access ctldl.windowsupdate.com and gets a timeout. Windows attempts to access ctldl.windowsupdate.com to check Certificate Trust List (i.e. Certificate Revocation List). With limited Internet connectivity, Windows may be unable to access it thus resulting in these delays.
If it's not your case, then I suggest contacting VisualSVN's support team for investigation.
In my case it was due ot Windows proxy settings - that you set in IE (I use TortoiseSVN client, and Visual SVN Server was set to use basic authentication).
After I've set up IE proxy settings accordinlgy (automatic for me, but for you it might be something different) initial delay was gone.
It helped even though the svn server is on local LAN and I have checked with Wireshark if the traffic goes over proxy. In Tortoise I have proxy disabled. Why it helped with my issue - no idea.
The initial delay I had was 11-13 seconds. Now next to none.
And I am not using ssh client.
Go to http(s) location of your SVN server using your browsers: IE, Fireofx, whatever, and if the response is quick then it is very possible that is an svn client problem, or due to some similar settings (similar to your browser settings).
For instance IE was slow (IE was set up for local connection only previously), Firefox (with proper proxy settings) was OK - and SVN server IS local (sounds like some sort of network/firewall/routing issue to me, but proxy settings helped me).
I know it is not strictly a programmer question, on the other hand, I would really like to be able to do a simple svn up on the production servers, which would save us a lot of hassle.
Or production servers are within a corporate network, and access is only allowed through a gateway server. From that we can access the actual servers via Remote Desktop. Because of this maintenance unfriendly setup we use a sftp server to get our files to the production server (where the ftp server alwys resets last modified date), so it is complicated to determine which files have changed.
So if it would be possible to setup a ssh tunnel from the actual server through the citrix connection, it would ease the whole update process.
(On further option which I consider is to use bazaar to push our updates to the sftp server and then pull the updates from there, but unfortunately there is no working svn plugin for bazaar available [on windows])
Okay, not wanting this to remain unsolved, I posted the following on the usenet in alt.os.citrix:
G'day everyone
Someone asked me this question. I haven't a clue. Any ideas?
"the connection I have is PC -> Citrix Access Gateway -> actual Server. My question is, if it is possible to establish a ssh connection from my PC to the actual Server."
The response I got from a Catherine Jefferson was:
Should be. I do this all the time using an Access Gateway VPN, then ssh to servers inside the company LAN.
What version of the Access Gateway is this user running? I work for Citrix, might be able to get a more specific answer for him or her.
So may I suggest you hook into alt.os.citrix (probably via Google Groups if you don't have an NNTP tool) and buy into the conversation.
--Bruce
I do this a lot. The tunnel is like:
ssh -nvCXAN -L 1494:10.0.2.39:1494 www.starshipping.com &
Then, you need an ICA file that points to localhost.
[WFClient]
Version=2
[ApplicationServers]
Connection To Citrix Server=
[Connection To Citrix Server]
WinStationDriver=ICA 3.0
TransportDriver=TCP/IP
ClientAudio=Off
DesiredColor=8
Username=yourusername
Domain=yourdomain
Password=xxxxxxxxx ; has to be encrypted. I pulled from another ICA file generated internally
ScreenPercent=97
TWIMode=OFF
Address=localhost
This all worked very fine on OSX until Citrix gave out a new version of the Citrix client which is now called the Citrix Online Plugin. Haven't been able to get it to work since then. Meanwhile, our VPN has been working fine, so haven't worried too much about it.
Citrix over SSH, How to Create a Key Pair for SSH Authentication Using PuTTYgen, Terminals. It seems that the answers are "out there" but not readily found. That was just five minutes in Google. HTH.