voludu2 wrote:The bigger risk to users is probably not links back to waze, but links to google docs, because they involve google logins, which could compromise your google account.

It appears that the waze website uses some mechanism to force attempted http connections to become https, thus preventing the problem on links to waze sites.

Links to other sites, which might be vulnerable to this kind of attack, are the ones that could pose a risk to wiki users.

While I agree there is a problem beyond Waze pages, I don't think Waze pages are immune from this MITM attack. After reviewing that last video in its entirety, I now understand that the hack occurs at the point your browser requests the HTTP URL from the target website. Because the initial request is to HTTP, the hack SW will spoof the HTTPS server and pretend to be that HTTPS server before you are redirected to the HTTPS link.

If you instead start your initial request for HTTPS, then the hack SW is unable to spoof the target HTTPS server and would fail, preventing you from disclosing login credentials.

CoolCanuck wrote:For links, you can use //Google.ca or //Wikipedia.org doing so should avoid the blue lock icon (frowned upon!). and automatically select http or https. Not all sites have https. Do NOT use https for every link!

I am pretty confident using //Wikipedia.org and http://Wikipedia.org are the same. In both cases the browser starts a standard http link with the host server. If the server redirects to the https secure link, then you automatically get transferred to the secure page.

Therefore using //Wikipedia.org is no different and is still exposed in the same way.

As mentioned previously, we can create a template (maybe we already did) to display secure links without the lock symbol. Or we can ignore it if we believe no one is confused by the meaning of the lock.

CoolCanuck wrote:Please see this wikipedia article, as our style guide is very similar. https://en.wikipedia.org/wiki/Help:URL# ... and_https:

using // also helps prevent "unsafe resource" browser warnings when an image/script over http:// is loaded from the secure wiki. There is a difference.

Thanks for the link and it does look like that includes most of the solution we need here.

Inside our Wiki we use internal links with the [[TERM]] format, so we never have that condition.

If you are on Waze Wiki and are already connected using HTTPS: and you link to a page outside of the Wiki on a different server, then this format seems to allow the initial link to automatically use HTTPS: to the external source. If that server is not secure, it should automatically drop down to HTTP: and that would be fine.

The only limitation would be if you are in an insecure server initially when you click that link. However in the case of our Wiki, it is always HTTPS: so you should always be covered.

I see from the examples on the page this also removes the lock icon issue.

Does anyone see any downside to this proposal from CoolCanuck? If not I propose we start implementing on pages as we make changes. Maybe when qwaletee gets his server back up we can just run this through the automated script for a global change.

CoolCanuck wrote:The flaw is that links are not automatically formatted. (you have to use [//example.com]. Not a huge disadvantage, since we name our links eg [//wikipedia.org Wikipedia]

Please clarify. Are you saying with this option we cannot name links and we have to use the actual link name?

Ah. Yes we format all links in the Wiki anyway, so that is not a problem.

This is all much ado about nothing. As kent said earlier in the conversation, Waze automatically forces https via redirect for its own web pages. You will never see http.

MITM attacks are more difficult than they used to be, because the network stacks - and especially the network infrastructure - is aware of them. Simple ARP poisoning rarely works anymore.

Phones are no more vulnerable than laptops anymore, unless you are using a circa 2009 flip phone.

Of course there's an attack vector. But it is an exceedingly small one. Security is always about balancing requirements.

I've worked in network security for the past 10 years. You have a point of view, and you've used it to insult me. In network security, we evaluate threats based on risks and consequences.

Man in the middle is considered a low vulnerability on local open networks, and the risk is generally mitigated by other factors, though that is hard to control in the general Internet population.

You'll also note that Google does not encourage https in its place links - for the same reasons. Google is well aware of the security concerns, and it does not rise high enough to override the difficulty/awkwardness it would place on its in-house and community authors, nor the negative user experience that https can sometimes cause (e.g., certificate errors).

Thank you for your time. I'll go back to my professional life now while you lecture me on such basic network tech as IP and DNS.

top_gun_de wrote:Anybody with basic knowledge about IP and DNS in particular would disagree, but that is beyond this forum.

Best regards,

Detlev

I know this because when you edit Google maps, there is nothing that requests that you use https URLs, and in fact, it appears to be rare to find an https URL in GMaps.

I do see that this thread is wiki-edit specific, I may have confused it with another thread that discussed making https a standard in places as well. Doesn't really matter though, as the points all remain the same.

The last comment is not entirely correct.

A redirect from http to https does not mitigate the risk behind a non-secure http-connection. If an attacker is able to get into a man-in-the-middle-position, i.e. through DNS attacks or by manipulating network infrastructure, the http-request will reach the man in the middle. The redirect at the Waze-firewall does not affect this possibility.

It is merely a remediation that gets users to the content who don't care about the right protocol and the right address.

But this disgresses, I know

Best regards,

Detlev