SSL is broken in Safari (because of IPv6)

[ameshkov]

The issue I noticed with some HTTPS sites not working in Safari still happens. For example, it'll happen if I boot the Mac partition then start Safari and it'll attempt to load my homepage https://news.google.com/ and it'll end up giving off an error. It only happens the first time though when Safari is set to Google News as my homepage. Refreshing the page or opening Google News in a new tab works fine. It's just the first load when it does it.

We have three situations:

1. IPv6 address is not available (everything is ok)
2. IPv6 address is available AND IPv6 connectivity is ok (everything works good in this case)
3. IPv6 address is available AND IPv6 connectivity is NOT ok (that's our issue)

We should detect network change (for instance like it's done here http://stackoverflow.com/questions/11532144/how-to-detect-ip-address-change-on-osx-programmatically-in-c-or-c) and check IPv6 connectivity.

[BooBerry]

Some things to note for this;

• It only seems to happen on the first page load. Refreshing or re-opening the page in a new tab works fine. To try to reproduce the issue again, you'll need to reboot the Mac.
• Having Safari set to a HTTPS homepage, in my case https://news.google.com/ and setting Safari to load a home page when opening Safari seems the best way to reproduce this issue.
• It'll happen randomly on other HTTPS sites - Netflix, Wikipedia, YouTube, Google, etc.

[ameshkov]

@AwesomeDonkey one more thing: could you please take a screenshot of the error?

[BooBerry]

Yup, here you go: http://i.imgur.com/OuJ3yXu.png

Sadly it's not very descriptive.

[ameshkov]

Good enough, thank you!:)

[BooBerry]

Interesting, it's real easy for me to reproduce repeatedly on https://www.yahoo.com/

[ameshkov]

I guess we'll need debug logs here.
@Stillness-2 could you please come here?

[Stillness-2]

yes, we need to compile debug build specially for @AwesomeDonkey, and try to receive debug log.

[BooBerry]

Alright, I'll be ready!

[Stillness-2]

This is the link to the debug version: https://www.dropbox.com/s/ctig2ihmzqq8i94/Adguard.zip?dl=1

Test instructions.

close all browsers
close Adguard
open debug version Adguard and enter admin login/password when prompt appears
when Adguard becomes «green» close it
open Console.app, and find ProtocolFiltersLog.txt

delete ProtocolFiltersLog.txt
then open Safari with a blank page
open debug version Adguard
in Safari, enter https url, for example https://news.google.com/
close Adguard if error occurs.
in Console.app find ProtocolFiltersLog.txt, and send it on devteam@adguard.com

Thank you! :)

[BooBerry]

Got it, sent it in.

The mail is called Mac Safari ProtocolFiltersLog.txt

[BooBerry]

Did another from Google News and sent it in, same subject as above with Google News added.

[ameshkov]

@Stillness-2 told me that this issue is more like our old IPv6 problem (when browser decides that ipv6 is available and tries it prior to ipv4).

[BooBerry]

Interesting. Until yesterday for the last month or so I've had IPv6 disabled. I re-enabled it last night but haven't tried testing Safari again.

[BooBerry]

Yep, confirmed. With IPv6 re-enabled, Safari seems to be working fine now without this issue.

So I assume this can be fixed, yes?

[ameshkov]

Not yet:) Now we know that the issue is not with SSL, but with our IPv6/IPv4 support:)

We should come up with some way to properly check if IPv6 is available and do not try to handle IPv6 connections in the cases like yours.

So will you be able to test a patch when it's ready?

[BooBerry]

Yep, I can test the patch when it's ready. :)

[ameshkov]

@Stillness-2 I've updated issue text, plz take a look

[ameshkov]

Hey @Stillness-2, instead of closing maybe you give @AwesomeDonkey a test build to check it?

[Stillness-2]

@AwesomeDonkey, new test build: https://www.dropbox.com/s/ctig2ihmzqq8i94/Adguard.zip?dl=1
In this build bug must be fixed.

[BooBerry]

Yep, encountering no more issues here with Safari (posting from it right now). :)

[ameshkov]

Thanks god, finally! @Stillness-2 good job, thank you!

[ameshkov]

One more thing: we should not cache connectivity check result if it is unsuccessful.

For instance, this may be some sort of a temporary network issue. So if we have cached that unsuccessful result, it will break connection even when network is stable again.

[Stillness-2]

Now, kext caches only positive result of the connection checking. Also cache timeout is 60 sec.