DNSSEC is an availability issue, as recently demonstrated by the
Slack issue, with limited security advantage. DoH on the other hand
is a critical security upgrade. This change adds DoH support for the
non-DNSSEC endpoints of Quad9.
https://www.quad9.net/service/service-addresses-and-features#unsec
Signed-off-by: Filippo Valsorda <hi@filippo.io>
(cherry picked from commit d7ce2be5f4)
Like mentioning which cert domain(s) are valid.
(cherry picked from commit 891e7986cc)
(cherry picked from commit b10a55e4ed)
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
It was in the wrong filter direction before, per CPU profiles
we now have.
Updates #1526 (maybe fixes? time will tell)
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
(cherry picked from commit 080381c79f)
So SOCKS5 dialer can dial HTTPS cert names, for instance.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
(cherry picked from commit 29a8fb45d3)
This fixes "tailscale cert" on Synology where the var directory is
typically like /volume2/@appdata/Tailscale, or any other tailscaled
user who specifies a non-standard state file location.
This is a interim fix on the way to #2932.
Fixes#2927
Updates #2932
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
We unconditionally set appropriate perms on the statefile dir.
We look at the basename of the statefile dir, and if it is "tailscale", then
we set perms as appropriate.
Fixes#2925
Updates #2856
Signed-off-by: Aaron Klotz <aaron@tailscale.com>
ProgramData has a permissive ACL. For us to safely store machine-wide
state information, we must set a more restrictive ACL on our state directory.
We set the ACL so that only talescaled's user (ie, LocalSystem) and the
Administrators group may access our directory.
We must include Administrators to ensure that logs continue to be easily
accessible; omitting that group would force users to use special tools to
log in interactively as LocalSystem, which is not ideal.
(Note that the ACL we apply matches the ACL that was used for LocalSystem's
AppData\Local).
There are two cases where we need to reset perms: One is during migration
from the old location to the new. The second case is for clean installations
where we are creating the file store for the first time.
Updates #2856
Signed-off-by: Aaron Klotz <aaron@tailscale.com>
tailscale-ipn.exe (the GUI) shouldn't use C:\ProgramData.
Also, migrate the earlier misnamed wg32/wg64 conf files if they're present.
(That was stopped in 2db877caa3, but the
files exist from fresh 1.14 installs)
Updates #2856
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
C:\WINDOWS\system32\config\systemprofile\AppData\Local\
is frequently cleared for almost any reason: Windows updates,
System Restore, even various System Cleaner utilities.
The server-state.conf file in AppData\Local could be deleted
at any time, which would break login until the node is removed
from the Admin Panel allowing it to create a new key.
Carefully copy any AppData state to ProgramData at startup.
If copying the state fails, continue to use AppData so at
least there will be connectivity. If there is no state,
use ProgramData.
We also migrate the log.conf file. Very old versions of
Tailscale named the EXE tailscale-ipn, so the log conf was
tailscale-ipn.log.conf and more recent versions preserved
this filename and cmdName in logs. In this migration we
always update the filename to
c:\ProgramData\Tailscale\tailscaled.log.conf
Updates https://github.com/tailscale/tailscale/issues/2856
Signed-off-by: Denton Gentry <dgentry@tailscale.com>
I had updated VERSION.txt to 1.14.1, tagged and pushed the tag, then
noticed that continuous integration failed because the list of DERP
servers for emergency DNS fallback needed to be updated.
I tried to revert VERSION.txt, delete the tag, update DERP, and tag
again but it won't import in the next step because the checksum is
wrong. I had deleted the tag and moved it, and something out there
wants none of that funny business.
Honestly I'm kindof glad, gives confidence in the integrity of
the tree.
ANYWAY, 1.14.1 is unusable and we're going to 1.14.2.
Signed-off-by: Denton Gentry <dgentry@tailscale.com>
This test is highly dependent on the accuracy of OS timers.
Reduce the number of failures by decreasing the required
accuracy from 0.999 to 0.995.
Also, switch from repeated time.Sleep to using a time.Ticker
for improved accuracy.
Updates #2727
Signed-off-by: Joe Tsai <joetsai@digital-static.net>
(cherry picked from commit 30458c71c8)
Unfortunately this test fails on certain architectures.
The problem comes down to inconsistencies in the Go escape analysis
where specific variables are marked as escaping on certain architectures.
The variables escaping to the heap are unfortunately in crypto/sha256,
which makes it impossible to fixthis locally in deephash.
For now, fix the test by compensating for the allocations that
occur from calling sha256.digest.Sum.
See golang/go#48055
Fixes#2727
Signed-off-by: Joe Tsai <joetsai@digital-static.net>
(cherry picked from commit 3f1317e3e5)
It wasn't using the right metric. Apparently you're supposed to sum the route
metric and interface metric. Whoops.
While here, optimize a few little things too, not that this code
should be too hot.
Fixes#2707 (at least; probably dups but I'm failing to find)
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
(cherry picked from commit 3606e68721)
To be scraped in the Go expvar JSON format, as a string is involved.
For a future tool to record when processes restarted exactly, and at
what version.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
If a peer is connected to multiple nodes in a region (so
multiForwarder is in use) and then a node restarts and re-sends all
its additions, this bug about whether an element is in the
multiForwarder could cause a one-time flip in the which peer node we
forward to. Note a huge deal, but not written as intended.
Thanks to @lewgun for the bug report in #2141.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
This log is quite verbose, it was only to be left in for one
unstable build to help debug a user issue.
This reverts commit 1dd2552032.
Signed-off-by: Denton Gentry <dgentry@tailscale.com>
This is useful for manual performance testing
of networks with many nodes.
I imagine it'll grow more knobs over time.
Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>
Intended to help in resolving customer issue with
DNS caching.
We currently exec `ipconfig /flushdns` from two
places:
- SetDNS(), which logs before invoking
- here in router_windows, which doesn't
We'd like to see a positive indication in logs that flushdns
is being run.
As this log is expected to be spammy, it is proposed to
leave this in just long enough to do an unstable 1.13.x build
and then revert it. They won't run an unsigned image that
I build.
Signed-off-by: Denton Gentry <dgentry@tailscale.com>
