ti_ranger

> Productivity-wise, MFA will work better than USB tokens - I know a bunch of people who regularly forget their work smartcard pass, I don't know many people that forget their mobile phone.

(Your terminology is weird. What do you mean by MFA where USB tokens aren't in-scope? I guess you mean an authenticator app on a mobile device).

Where I work, we use Yubikeys, which are used as 2FA for almost everything: * SSO on all web internal web sites, the SSO implementation supports U2F * short-lived (less than a day) ssh certs signed by Yubikey OTP * VPN access authenticated by Yubikey OTP

Enrolling of yubikeys is self-service, and supports up to 2, and employees in critical positions can have 2. Re-setting the Yubikey OTP pin is mostly self-service, but you need to enter it any time you VPN or get a new ssh cert, so you are more likely to forget your phone at home than your Yubikey OTP pin.

> I feel like security gimmicks like these distract them away from fixing real problems and are, if anything, detrimental to security.

Many banks (especially in my country) rely on SMS OTPs. Some banks have OTP authentication for their websites on their mobile apps (but then if you uninstall the app, you have to re-enroll, which is quite tedious).

I would much prefer all banking sites to support U2F/WebAuthn, and hopefully that would also sufficiently motivate good support on phones for U2F/WebAuthn. If they allowed you to turn off any SMS-based OTPs (e.g. if they support recovery codes and 2 tokens), I think it would be possible to eliminate SIM-swap fraud (which is quite rife here ...).

And to be clear, I don't mean this in place of good password managers, I mean in addition to password managers. Defense-in-depth and all.

To add to my previous answer:

> While AWS has ruffled a bunch of feathers with their Elasticsearch and Kafka managed offerings which can be easily construed as attempts to steam roll the respective open source-first entities, I am actually quite impressed by the mechanism that Azure has employed with Azure Managed Applications:

Here ( https://aws.amazon.com/marketplace/pp/B01N6YCISK?qid=1572333... ) is Elastic Co's ElasticSearch SaaS offering on AWS: > Elasticsearch Service on Elastic Cloud > Sold by:Elasticsearch Inc. > The official hosted Elasticsearch & Kibana offering on AWS. Launch, manage, monitor and secure Elasticsearch and Kibana deployments with the latest versions, and add machine learning and powerful hot-warm architecture with optimized templates.

The other popular product/software to hate on AWS about is MongoDB, which we find here: https://aws.amazon.com/marketplace/pp/B077D557RX?qid=1572333...

> MongoDB Atlas for AWS > Sold by:MongoDB > MongoDB Atlas delivers the world's leading database for modern applications as a fully automated cloud service with operational and security best practices built in. Easily deploy, operate, and scale MongoDB on AWS by letting Atlas take care of time-consuming administration tasks.

I haven't used any of these, but the reviews seem to show that people are running them.

So, your assertion that Azure has shown creativity, when AWS launched the ability for partners to offer SaaS solutions on AWS (with recent improvements such as PrivateLink to allow SaaS partners to offer managed services inside customer VPCs) 2 years before Azure indicates that seem to not be familiar enough with AWS to be making these statements.

> I am quite surprised that its Azure that has shown creativity here while AWS and Google have limited themselves to offering marketplace AMIs/images at ridiculous markups.

Are you sure that is accurate for AWS?

https://docs.aws.amazon.com/marketplace/latest/userguide/sof...

This seems to have launched in 2015: https://aws.amazon.com/blogs/apn/saas-partner-program/

Azure Managed Applications launched in 2017: https://azure.microsoft.com/en-us/blog/managed-applications-...

Google's offering seems to have launched this year.

> You can still set 1.1.1.1 as your DNS resolve in your DHCP server if you want to trust your ISP.

It's not that I necessarily trust my ISP, I don't want to be forced to also trust Cloudflare (both for privacy and availability).

So no, I don't use 1.1.1.1, I run my own recursive name server.

> There's also no trust with ISPs. They've already all lobbied at the Congressional level to legally sell our data.

Yes, for you Americans.

Please, go fix your politicians, rather than inflicting technical "solutions" to political problems on the rest of the world.

> DoH is a vendor-neutral protocol.

But there are still gaps regarding discovery of DoH servers.

> DoH is simply DNS transmitted over a secure encrypted medium, whereas existing DNS is transmitted over an insecure unencrypted medium.

I think you're confusing DoH and DoT.

> It's very similar to HTTP vs HTTPS.

No, it isn't.

1)It is common to HTTP-redirect to HTTPS, and none of the DoH proponents have proposed/standardised discovery of DoH, as far as I can tell.

2)DoH means that suddenly many "features" of HTTP infect DNS, such as cookies. The RFCs allow for cookies, the question is, what cookies does Mozilla send in DoH requests, and what does Cloudflare do with them?

> Somehow, groups that stand to gain a lot by continuing to be able to read and intercept DNS traffic have led a successful astroturfing campaign against DoH by conflating it with one specific implementation in Firefox that happens to use Cloudflare as default provider (though of course with the ability to choose other providers, as you can for search engine).

Not only "groups that stand to gain", but users who stand to lose more privacy by exposing their DNS requests to Cloudflare by default.

DoH may be good (I think DoT would be better), and surely Mozilla could do a better job of encouraging DoT and/or DoH support by working to get better discovery of DoH and/or DoT instead of forcing all DNS traffic (for users it has identified are in the U.S., and by the way, how does it do that without additional privacy concerns) to a (to me) un-trusted third party.

Actually, I think in my country, if they do this, Mozilla would fall afoul of traffic interception laws.

> The Cloudflare DNS servers you connect to are in the EU and are subject to EU regulation just like your ISP.

In my (non-EU) country, ISPs are subject to relatively strict regulations, and Cloudflare doesn't fall under those regulations.

> One thing to consider also is that unencrypted DNS means that virtually anyone can read (and modify) those requests

Not "virtually anyone", it would require physical access to the GPON fibre between my home and the MSAN/CO/Exchange (non-trivial, scales really bandly), or the MetroEthernet backhaul from the MSAN to the BNG (where they would trip alarms and the last-mile provider would investigate). From the BNG onwards traffic is encrypted on-the-wire (MPLS with group encryption as far as I know) until it is handed over to the ISP. My ISP co-locates caching DNS with their hand-over routers, so here it would require tapping the fibres in their data-center (not happening without their knowledge).

Also, someone who is just mass-collecting my DNS requests without any other identifying data, and no ability to correlate IP address to users, has limited privacy exposure.

A centralised third-party, who can correlate source IP addresses with user-identifying browser cookies from other HTTP requests in the same time window seems like a much bigger privacy concern.

Americans, please sort out your last-mile provider+ISP monopolies (e.g. lobby your politicians for regulations that enforce competition), so that you can stop forcing unnecessary technical solutions on the rest of the world, who doesn't have this problem (if ISPs do anti-customer things, they lose business).

> I reached out to Mozilla, and they've confirmed that DoH is being enabled by default only for installations inside US.

How do they know? What is the likelihood of them getting it wrong?

What protections do they have in place for their geo-location, to ensure that they don't leak unnecessary information when determining whether a user is in the U.S. or not?

The article title, "Dear Email Industry, We’ve Got a GDPR Problem", implies that.

Either you do think email marketing comprises the entire industry, or the article title (and HN submission) are (or give the impression of) clickbait.

At least it doesn't seem you are doing any direct tracking on the post though ...

(I used to work for an ISP with a pretty large email service, so it touches nerves that were exposed when our enemies, those companies who try and find ways to irritate our customers, think they are the only important parts of the actual email industry)

> They can, it just takes extra steps.

For 99% of users, that means they can't.

Luckily for them, they probably aren't allowed to use Firefox anyway, and are stuck using Edge or whatever, and the local MCSE will use this as another reason why Firefox may not be used by anyone.

> But if they do DPI, it will be resolved once ESNI starts being deployed.

What if ISPs block requests with eSNI for all users, in order to be able to remain compliant with legal intercept legislation (e.g. warrant for suspected child porn investigation)?

There are conflicting desires with trade-offs, and all Mozilla is doing here is escalating the war, rather than trying to reach agreement with the rest of the industry on how to satisfy two different requirements.

My ISP is subject to specific regulations for licensed network providers, which Cloudflare isn't.

Thus, Cloudflare is the problematic intermediary.

Fastest isn't necessarily best.

My ISPs caching DNS, and any caching DNS running on IP addresses belonging/advertised by my ISP by BGP to various CDNs, are the best possible responses.

I don't care if the p99 DNS response from my ISP is 50% slower than Cloudflare, if the streaming video, or large download, or many small files requests are better served by CDNs in my ISPs network that are not visible to Cloudflare.

All DNS benchmarks I have seen focus only on the DNS response time, never on the DNS response quality.

But that's because they are mostly written by people who don't know how the internet (or competent ISPs) actually work. Some of them even seem to log errors when they get unexpected responses for some well-known URLs (like google.com) because they don't know there are new Google sites than when they last checked ...

> What are the arguments against eSNI?

Institutions providing internet access, but with an obligation or operational requirement to block certain kinds of content (e.g. insufficient network capacity on the free WiFi at a hospital to allow streaming video for all visitors) would not be able to do it at all.

Privacy proponents seem to forget that there are sometimes reasonable reasons to allow traffic to be blocked, and instead of looking for a real solution, are imposing ridiculous "solutions" on all Firefox users.

> Then it would be easier for an ISP to block encrypted DNS (by port number). It is better to masquerade everything as normal HTTPS to make blocking more difficult.

For most people, if you can't trust your ISP, you have bigger problems.

For people who can trust their ISP, why should we all by default be affected by the fact that the Mozilla developers seem to all live in a non-free or non-democratic country.

Maybe they should instead focus on fixing the US political system that results in their current situation, rather than trying to use technical means to solve political problems.

> The only motivation your ISP has for logging this is making money; if getting the information is too tedious and expensive why would they bother?

I used to work at an ISP.

We configured (wrote policy language for) our DPI platforms to do header inspection of all HTTPS traffic to measure customer experience to different websites, to improve the customer experience.

The raw data was (theoretically) accessible to ~4 people and deleted as soon as ETL had succeeded, and the anonymised results (aggregated only by region, product etc.) were available to the operations team (another ~8) and product management (~4).

This complies with our countries personal information regulations.

Mozilla proponents seem to be quite anti-ISP.

Why is that?

>> What happens if they get a FISA warrant?

> They have to follow the law? Wrong threat model.

If this happens for non-US citizens, this is violation of privacy laws of the affected user.

If this is rolled out, I will either ensure my distro switches this off by default, or have to consider changing browsers (away from Firefox).

> To mitigate this risk, our partners are contractually bound to adhere to this policy.

You seem to think that: 1)No company in the history of the world, has ever violated a contract?

2)No government has ever forced a company to give up information that it is contractually obliged not to give up

3)No hacker has ever hacked into a company's systems and exfiltrated data the company was contractually obliged not to share

You seem to think that if a contract has been concluded, it is impossible for it to be violated.

Then there are also the problems of making all Firefox browsers depend on the availability of CloudFlare.

> In followup, turns out they didn't even lose data as claimed.

Link?

> All of S3 has, but that’s because S3 had a single choke point in a single region for a long time.

The only S3 event here was limited to us-east-1: https://aws.amazon.com/premiumsupport/technology/pes/

Some APIs were impacted, because they are global by nature (e.g create-bucket). But S3 was working fine in all other regions, for existing buckets.

However, many websites were affected, because they didn't use any of the existing S3 features that allow for regional redundancy, simply because S3 had been so reliable they didn't know/think they needed to have critical assets in a bucket in a 2nd region that they could fail over to.

Admittedly, even the AWS status page was impacted, because it also relied on S3 in us-east-1.

S3 has done a lot of work to improve matters since, and mechanisms have been put in place to ensure that all AWS services don't have inter-region dependencies for "static" operation.

However, it is still incorrect to claim that it was all of S3. Many customers who use S3 only in other regions were totally unaffected.

> Back when I worked there, the AWS status board was (and probably still is) terrible b/c Service teams owned that communication channel, not AWS Support. That really ought to have been changed.

It has.

> Service teams don't have the time or incentive to give real-time updates. Why not just let the people who know the customers best deal with parsing the TT and giving updates?

The escalation team inside PS now drafts customer messaging within ~5 minutes of the impact being identified (usually about 5 minutes into an event) and if the impact is significant enough to post to the public dashboard, than may take another 5 minutes. Depending on the type of impact, affected customers will be notified via the personal health dashboard.

PS owns the tooling that does this, and is responsible for driving the process, but the service org's (e.g. EC2, S3 etc.) representative often makes the call on whether to post to the public status page or not (depending on the scale of the impact, e.g. 20% API failure rate for 5% customers probably won't make the status page, but affected customers will get notices). TT is almost out ... but the PS tooling supports it and its replacement, and provides easy access and summaries for internal teams (so you don't need to refresh TT or subscribe to the ticket just to see what the status is).

> We make software deployments constantly across the network and have automated systems to run test suites and a procedure for deploying progressively to prevent incidents.

Good.

> Unfortunately, these WAF rules were deployed globally in one go and caused today’s outage.

Wow. This seems like a very immature operational stance.

Any deployment of any kind should be subject to minimum deployment safety, that they claim they have.

> At 1402 UTC we understood what was happening and decided to issue a ‘global kill’ on the WAF Managed Rulesets, which instantly dropped CPU back to normal and restored traffic. That occurred at 1409 UTC.

Many large companies would have had automatic roll-back of this kind of change in less time than it took CloudFlare to (apparently) have humans decide to roll-back, and possibly before a single (usually not global) deployment had actually completed on all hosts/instances.

However, what is more concerning is that it seems you shouldn't rely on CloudFlare's "WAF Managed Rulesets" at all, since they seem to be willing to turn it off instead of correctly rolling back a bad deployment, which they only did > 43 minutes later:

> We then went on to review the offending pull request, roll back the specific rules, test the change to ensure that we were 100% certain that we had the correct fix, and re-enabled the WAF Managed Rulesets at 1452 UTC.

How were they not able to trivially roll back to the previous deployment?

From the article:

> AWS has the most granular reporting, as it shows every service in every region. If an incident occurs that impacts three services, all three of those services would light up red. If those were unavailable for one hour, AWS would record three hours of downtime.

Was this reflected in their bar graph or not?

Also, GCP has had a number of global events, e.g. the inability to modify any load balancer for >3 hours last year, which AWS has NEVER had (unless you count when AWS was the only cloud with one region).

>> Here are the S3 numbers: https://aws.amazon.com/s3/sla/

> 99.9%

(single-region)

There doesn't seem to be an SLA on S3-cross-region-replication configurations, but I am not aware of a multi-region S3 (read) outage, ever.

> https://azure.microsoft.com/en-au/support/legal/sla/storage/....

> 99.99%

99.99% is for "Read Access-Geo Redundant Storage (RA-GRS)"

Their equivalent SLA is the same (99.9% for "Locally Redundant Storage (LRS), Zone Redundant Storage (ZRS), and Geo Redundant Storage (GRS) Accounts.").

>> You could very easily reach 100 GByte/s read which no network will match.

> High end networking gear already has higher throughput:

100GB/s > 200Gbps

You would need 4x 200Gbps ports to reach 100GB/s, so 2x MCX653105A-ECAT (each 2x 16-lanes) at > $700 each, and pay for 1/10th of a ~$30 000 switch, IOW 100GB/s would cost you ~ $4400, before paying for the storage.

Sure, it could be done, but it wouldn't be cheap, and you'll have used most of the PCIe lanes.

You mean the link this thread is about?

"Building a high performing home NAS"

"I was averaging 60-113mbps depending on the size of files being moved. This was a successful build in my mind! After selling my QNAP NAS, I came out ahead on my expenses for the build."

113Mbps is considered "high performing"?

"on a shoestring budget with the Rock64 SBC"

"TOTAL: $172.39 CAD before tax"

This is without the cost of the hard drives, doesn't seem ot include the cost of an enclosure, and results in:

* 1 Quad-core A53

* 2GB ram (the 4GB version is $45 USD without shipping, so it couldn't have been this one), which you can't ever change

* 0 SATA ports

* 1 USB 3 port

* 2 USB 2 ports

* 1x GbE

I would probably rather consider an HP Micro Server (e.g. https://www.amazon.com//dp/B079MFYDSL ), which for $282 provides:

* 1.6GHz dual-core Opteron

* 2 DIMM slots, 8GB DDR4 provided

* 5x SATA ports (4x in the disk bays, 1 in the optical bay)

* 4 USB3 ports, 2 USB2 ports, internal USB port

* 2x GbE

* 2x PCIe slots

* Hardware RAID support (I wouldn't use it, but it's available).

It would meet all of these requirements the poster had:

* Shoestring budget, under $300 preferred

* Scalable, not locked into a certain number of drive bays

* Gigabit ethernet

* USB 3.0 (for fast backups to my backup drives)

Preferred: compatibility with open source NAS offerings (OpenMediaVault, FreeNAS, etc.)

Low power usage (I don’t have high computing requirements for this system, so it doesn’t need to be driving up my electricity bill to run every month)

(I guess the Rock64 may have lower power consumption, but I don't think vastly lower).

I have a much older Microserver G7 (or NL54), which was much cheaper (I paid about $100), and it's great.

Edit: formatting

> I heard https://nvd.nist.gov/vuln/detail/CVE-2019-1804 is Cisco's ninth backdoor so far this year.

Also the 9th they have fixed.

> Not ninth security problem total, ninth backdoor. The ninth security problem Cisco shipped intentionally.

How can you be sure it was intentional?

> Meanwhile, the router that serves my office is from a company that's had fewer than nine security problems in the past ten years.

How can you be sure? Did you audit all the source code yourself? Did you compile the source code yourself and are you running only binaries you compiled? Are you sure you can trust the compiler you used?

Or, are you assuming that, because there isn't a CVE, there isn't a vulnerability or security problem?

Fewer CVEs doesn't necessarily mean more secure, it may just mean less validation/testing etc.

But sure, it could mean more secure, it's just not a guarantee.

> But you have to live under the wing of your distro mantainers, instead of installing whatever you want from any third party. Isn't Linux supposed to be about freedom?

You don't. Yes, but if you don't take advantage of the freedom, that's not freedom's fault.

> Yes, you can install software using tarballs, but it's not usable for 90% of users, and not because of the distribution model, but because of the lack of standardization in a good, easy to use application-installing API.

See Flatpak. Go look at what software is available at https://flathub.org/apps , but both GNOME and KDE have application managers that can install from Flatpak repos (configured to use Flathub by default), and possibly the distro's native package manager as well (via PackageKit).

Or you can also use AppImage files.

> because then you have to spend 40 minutes trying to install all the dependencies and building the package from source, instead of the 3 minutes it would have taken to install an .exe on Windows.

No, you take 2 minutes to install it using flatpak, or download a .appimage file.

And if neither of those are available, you spend that 40 minutes packaging the software, and submitting it to the distro you use for inclusion.

(If it was already packaged, but not new enough, that's a ~5 min job to do the update for your distro)

> to use an application the distro didn't deem worthy of inclusion in their repo.

How did you come to this conclusion? Did you request the package be included in the distro you use? If so, and it wasn't provided, provide the bug report/feature request link ...