Can't use bitbucket any more. Your connection is not secure - https

I've been using Bitbucket for 2 years on my Macbook. Today I went to view one of my depots but I am getting the error message, Your connection is not secure. All other sites works, it's only Bitbucket.org that is giving me this error. I've tried using Safari and Firefox, neither work. I also can not connect using SourceTree. I am able to connect on my Windows computer so that rules out my router. I've deleted all expired certificates in Keychain and deleted cookies and cache. Does anyone know what the issue might be?
The Macbook's clock is set automatically and is displaying the correct time. In Firefox, when the website fails to load, I can see these 3 messages by clicking the Advance button,
bitbucket.org uses an invalid security certificate.
The certificate is only valid for search.dnsadvantage.com
Error code: SSL_ERROR_BAD_CERT_DOMAIN.
If I click on the last error, it opens another page which displays, https://bitbucket.org/ Unable to communicate securely with peer: requested domain name does not match the server's certificate. HTTP Strict Transport Security: true HTTP Public Key Pinning: false.
Is there somewhere else I need to go to locate more information about the error?

Looks like you've picked up a virus and/or malware:
http://www.fixingvirus.com/always-redirected-to-search-dnsadvantage-com-how-to-stop-it/
That link is for Windows machines so maybe check this for Macbook?:
https://www.fixyourbrowser.com/how-to/remove-adware-mac-osx-safari-chrome-firefox/
Note I don't vouch for above links but first ones that came up when I Googled for "search.dnsadvantage.com". Seems a common problem.

Related

Not able to intercept traffic from nike.com login request

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

Certificate validation using internet to validate unnecessarily?

I have an application that receives items from a high-speed scanner device. As the items are received, they are written to disk using SQL Compact. The following digitally signed Microsoft DLLs are used:
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceoledb40.dll
sqlceqp40.dll
sqlcese40.dll
I recieved a performance complain from a customer, and traced the issue using Microsoft Procmon to a TCP Reconnect failure when attempting to contact the site for certificate validation when we make calls to methods in these dlls. At first, I could not recreate the issue locally. After talking to their infrastructure people and developers, I learned that they must use a proxy for internet connectivity. Some of the customer's users (in the test environment) had valid proxy settings, and they got good performance from our application. Naturally when they turned their proxy settings off, the validation could not be done and the performance issue arose.
I attempted to recreate the issue by setting our machine up with false proxy settings to a non-existent machine. On my initial attempt, I still got good performacne from our application, and no attempt was made to contact the internet for cert validation. After looking at the cert's validation chain, I noticed that it derived from the certificate "Microsoft Root Certificate Authority". I then exported and deleted that Cert, and was able to reproduce the issue as determined by a comparison of logs.
I did the following tests:
Test 1:
1. Opened the proxy settings, and enabled them pointing to a non-existent address.
2. Ran a test.
Results: No performance issue.
Test 2:
1. Exported the “Microsoft Root Certificate Authority” cert and moved it to the untrusted folder.
2. Ran a test.
Results: The performance issue occurred.
Test 3:
1. Deleted the “Microsoft Root Certificate Authority” cert.
2. Started a test.
Results: The performance issue began occuring.
3. While the test was in progress and device was hesitating I removed the false proxy settings.
Results: The performance issue disappeared and the application recovered.
Tentative Conclusions:
1. That I can simulate the no internet access condition by providing false proxy settings.
2. If the “Microsoft Root Certificate Authority” cert is installed properly, the .Net infrastructure does not need to access the network to verify the necessary cert.
3. If not, it will attempt to validate via the internet connection.
Nevertheless, when the customer checked the certificates in the "Trusted Roots Certificates" folder of mmc->certificates-local computer. The "Microsoft Root Certificate Authority" certificate does appear there, and it seems to be identical to mine. Yet for some reason the use of the dll's causes certificate validation to attempt to access the internet resulting in a performance issue.
In the customer's situation, eventually devices will be used in production with no internet access.
My question is, is there a setting (registry, or GPO) that might cause certificate validation to always attempt to use the internet, regardless of whether the root certificate of the validation chain is installed in the local computer?
Can a setting be enabled that causes a certificate validation to access the internet to check to see if the root certificate has been revoked, for example?
Please feel free to ask questions if you need more information.
This appears to occur for SQL Server Compact 4.0 on any system with an invalid proxy configuration, as a Certificate Revocation List check is run each time the engine is loaded (which happens on the first call to .Open()).
Solution: To avoid this delay, which probably affects any signed app on the system in question, you must fix the configuration or disable the check. The check can be disabled via UI or via registry settings, as described here: http://digital.ni.com/public.nsf/allkb/18E25101F0839C6286256F960061B282
For additionla issues see my blog post here: http://erikej.blogspot.com/2013/08/faq-why-is-opening-my-sql-server.html

Safari refuses SSL connection to one server

I've got an intranet site setup which uses an SSL cert with a self-signed CA. On one of my Macs, Safari refuses to connect, with the "Safari can't open the page .. because Safari can't establish a secure connection to the server .." The Mac is running 10.11 (El Capitan) with the latest patch.
Chrome and Firefox are both able to connect to that server.
Safari is willing to connect to it if I use the IP address instead of the
DNS name.
In the logs I see com.apple.WebKit.Networking[3382]:
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9802)
Another Mac on the LAN is happy to connect to the machine by its DNS name
I suspect there's something wrong in the keychain, but I can't find any certs nor revocations for anything related to either the DNS name of the machine, or its CA.
Any suggestions how to debug this are very welcome. The other StackOverflow articles seem unrelated to my issue.
My solution to this issue was to revert my Apache Configuration SSL Cipher Suite back to the default setting in WHM. Hopefully this may be of help.
I recently ran into a similar issue with an iOS device on an intranet. I installed the self-signed root and issuing certificates on the phone, but continued to receive the message. After a lot of trial and error, I found that manually changing the DNS setting (tapping the 'i' icon next to the active wifi connection in the wifi settings) to Google's public DNS ("8.8.8.8") solved the problem.

Google Chrome doesn't trust mitmproxy's certfificates

I'm running mitmdump (from mitmproxy) on my Macbook Pro, and I'm connecting to the proxy through my Windows desktop PC.
However, Chrome (running on the PC) refuses to connect to so many sites because of the invalid certificates which mitmproxy provides.
Chrome throws the error: ERR::NET_CERT_AUTHORITY_INVALID
Here's what mitmdump shows:
But why? What's wrong with mitmproxy's certificates, why can't it just send back google's as if nothing happened?
I'd like to know how I can fix this and make (force) my desktop PC to connect to any website through my Macbook's mitmproxy.
Answering this question for people who may find this important now. To get the proxy working, you have to add the certificate as trusted in your browser.
For windows follow this: https://www.nullalo.com/en/chrome-how-to-install-self-signed-ssl-certificates/2/
For linux follow this: https://dev.to/suntong/using-squid-to-proxy-ssl-sites-nj3
For Mac-os follow this: https://www.andrewconnell.com/blog/updated-creating-and-trusting-self-signed-certs-on-macos-and-chrome/#add-certificate-to-trusted-root-authority
There are some additional details in the above links; tldr; import the certificate in your chrome://settings url and add the certificate as trusted. That shall do.
This will make your browser trust your self-signed certificate(mitm auto generated certificates too.)
The default certificates of mitmproxy is at ~/.mitmproxy/ directory.
Per the Getting Started page of the docs you add the CA by going to http://mitm.it while mitmproxy is running and selecting the operating system that you are using. This should solve your problem and will allow https sites to work with mitmproxy.
This is the expected behavior.
mitmproxy performes a Man-In-The-Middle attack to https connections by providing on-the-fly generated fake certificates to the client while it keeps communicating to the server over fully encrypted connection using the real certificates.
This way the communication between client and proxy can be decrypted. But the client has to actively approve using those fake certificates.
If that wasn't the case then SSL would be broken - which it isn't.
The whole story is very well explained here:
http://docs.mitmproxy.org/en/stable/howmitmproxy.html

Cannot Access http://<tfs-server>:8080

I've installed TFS 2008, but I can't seem to access the server. When I try to connect to it in Visual Studio, I can't. If I try by browser on a remote PC, I get a generic page cannot be displayed. On the server, I get a 403. Nothing was touched in IIS and the service is running as a Network Service. Any ideas?
try:
http://localhost:8080/Services/V1.0/ServerStatus.asmx. This will tell you if TFS is up and running. If you are getting anything else you need to look into IIS issues.
I wrote a blog post on diagnosing these types of TFS connections.
http://blogs.msdn.com/granth/archive/2008/06/26/troubleshooting-connections-to-tfs.aspx
The very first thing I do is confirm that it works for a known-good configuration – usually my workstation.
Providing that works and the server appears to be functioning, the next thing I do is ask the user to call the CheckAuthentication web service using Internet Explorer.
The URL for this is: http://TFSSERVER:8080/services/v1.0/ServerStatus.asmx?op=CheckAuthentication
By doing this check, I am doing four things:
Eliminating Team Explorer from the picture
Eliminating the .NET networking stack from the picture
Ensuring that Windows Authentication is working correctly (that’s why I say IE)
Ensuring that proxy settings are set correctly
In most cases I’ve seen, the TFS connection issues are because the proxy settings have changed or are incorrect. Because .NET and Visual Studio use the proxy settings from Internet Explorer, it’s important to have them set correctly.
In rare cases it’s beyond this. That’s when I start looking at things like:
Can you resolve the server name?
Can you connect using the IP address?
Are there HOSTS file entries? (see: c:\windows\system32\drivers\etc\hosts)
Can you ping the server?
Can you telnet to port 8080?
Does the user actually have access? Run TfsSecurity.exe /server:servername /im n:DOMAIN\User to check their group memberships
Have you changed your domain password lately? In some cases they’ll need to logoff the workstation and log back on again to get a new security token.
Is the computer's domain certificate valid? update the certificate: gpupdate /force
Hope this helps.
Turns out the time and date on my computer was not "close enough" to the time and date on the tfs server. Changed my system clock setting and problem went away.
What happens if you send a simple HTTP request to the server directly?
ie:
telnet 8080 [enter]
GET / HTTP/1.1[enter]
[enter]
[enter]
That might give a hint about whether IIS is actually serving anything. If you can do that on the server, what about from a different machine? If the results are different a good guess is there are some security/firewall issues somewhere. HTH a little.
I went through everything on a similar problem.
I logged onto my tfs server and connected directly there.
I also used a TFS admin tool I downloaded some time ago from Microsoft, and made sure I was in all the right groups and projects.
I then went back to the client PC with the problem, tried the services/1.0/serverstatus.asmx?op=CheckAuthentication Url again, and it worked this time.
AFter that full service was restored to my PC.
So I don't have the exact answer, but I would go through the checklists presented by Grant Holliday in his answer.
Add this to the cases for future users, as i had this issue on server 2016...
if your firewall allow only Domain and Private Network, it may not work on client. make sure you give public permission, if server network is set to public...
The error you may face:
ERR_CONNECTION_TIMED_OUT
for
http://fserver:8080/tfs

Resources