hn.algolia.com used to return a pair of cloudflare IPs: 104.16.46.55 and 104.16.45.55. Requesting hn.algolia.com from these IPs now results in an "Origin DNS error" from Cloudflare.
I interpret this to mean that there is another record missing, as well: whatever the origin was set to.
I am not sure about that. On my system that openssl invocation fails because the site doesn't staple the intermediate Letsencrypt R3 certificate, and openssl doesn't retrieve it while browsers do.
The error from Firefox is SSL_ERROR_UNSUPPORTED_SIGNATURE_ALGORITHM which seems to align to what I'm seeing on the signature algorithm returned. Lastly by setting my system wide policy to allow the LEGACY (Fedora's term) algorithms the website starts to work on Firefox.
It could very well be that the server is at fault here (based on what I've read this seems to be the case) and that's due to the Let's Encrypt cross signed certificate. But the reason it's failing to load on the client side is because some clients block SHA1 based signing algorithms and that's what the server is offering here.
I received one of the phishing messages as well as the follow up / apology. An interesting wrinkle is that both were handled by sendgrid and used the same dkim selector. I would guess that a set of sendgrid api credentials shared with some 3rd party service was compromised.
- One of our domains had a DKIM trust with Mailgun (3rd party)
- Mailgun was integrated with a planning service (4th party?)
- Planning service was integrated with a CRM (5th party?)
- CRM was integrated with a website (6th party?)
Website got pwned, spam ensues using the entire chain all the way back to our domain. This was a while ago but I think the website was pwned, leaked API credentials for the CRM, those were locked to only read the address book for sources (not even destinations! but '*' was allowed...) but because the software was crap the planning/calendaring service was registered as a 'source', which included API creds. The planning service itself was pretty good, no further grab-keys-via-API, but using what was already allowed you could send raw MIME messages and it would just use the Mailgun API it had access to.
Luckily for me, I was on a prometheus spree and had an exporter grab the Mailgun metrics every few minutes (Ironically to support the CRM team because they didn't have any good metrics of their own and did like to blame everyone else), so while it was configured to look for dips, it also triggered on spikes because those tend to end with dips too.
I think in the end nobody learned from it because every team/vendor covered their ass with "well we only run it in datacenters with firewalls so this is the cloud at fault" and I don't think anyone got flak for it (but some definitely deserved a fair bit).
I received one of these phishing emails, today, and also Namecheap's follow-up/apology. The phony email purported to be from DHL, which really stood out.
Both emails were handled by Sendgrid, passing spf, dkim, and dmarc. They appear to use the same dkim selector, though I suppose that isn't so important--just that the headers were convincing enough.
GPX replay is a proof-of-concept built on an API and map plugins I've been developing over the past year.
If you're interested, there are more features like the ability to view shade for any time/date/location throughout the year, search, building shadows, and high DPI mode available at the base url: https://shademap.app
Not the author, but have some experience with the mailgun api. AFAIK there's no sla/guarantee/redelivery for the webhooks, and they have to be setup for each domain. Looping the account to fetch all logs for the last 48 hours is relatively simple and robust.
OP here (actually, he is my co-founder, same company). I can confirm this experience, looping seems to work.
In our own setup, we fetch data for the last 24h twice a day and then just insert everything. We have a db constraint on the message ID mailgun sends us, so only news ones will be persisted. We aren't even bothered with filtering before inserting, the db constraint does the trick.
I am confused by this—-aren’t ASICs the costliest option until some (high) number are fabricated and put into use?
If FPGAs can implement these changes efficiently—more efficiently than cpu miners—-and be re-synthesized to implement further changes, doesn’t that advantage them?
Thanks yes I totally meant scale. Main cost of new ASIC chips is design and fabrication. Only serve a very narrow specific purpose and all that cost is sunk. But after that, unit production chip cost is negligible.
"How would you decide when to use an FPGA and when to create an ASIC? That depends. FPGAs waste a large amount of silicon compared with an ASIC, so the cost floor, which depends in large part of the surface area of silicon required for the chip, is often an order of magnitude higher than you’d want it to be. But fabricating an ASIC isn’t cheap either."
ASICs are only costly from an R&D perspective. Which means once someone has all the R&D, they can be a monopoly and get really cheap hashrate, and since they are an incumbent monopoly it's much harder for another company to step in and complete.
I mean, a serious FPGA lab would simply keep their FPGA techniques secret until they build a sizable advantage. There's a lot of tech that would be built up: a custom memory controller, an implementation of various Cryptocoin PoW systems, and of course, the Bill of Materials for the ideal power-efficiency for various designs, etc. etc.
Something like an FPGA + Interposer to HMC would be a huge R&D effort, and just as centralizing.
BTW: None of the designs I've talked about are strictly speaking commodity. They'd require at a minimum, custom PCBs. Maybe more advanced techniques for the best technology (again: Custom Interposer to HMC + FPGA interface + all the Verilog / VHDL code to make it happen).
As long as an FPGA-based shop kept their FPGA PCB secret, as well as their code secret, and their Device Drivers secret (You'd probably run Linux / Windows to talk to the FPGA over PCIe) then they're basically going to be ahead of the rest of the competition. Eventually, the competition would catch up, but a constant R&D effort into newer designs (ie: testing HBM2 vs HMC vs RLDRAM3 vs QDRIV, building relationships with suppliers, etc. etc.) could lead into a sustainable business edge.
Heck, early on in Monero's life, some dude got to like 40%+ of the entire network's Hash Rate by simply writing better CPU code and keeping it for himself, and then spending hundreds-of-thousands of dollars on AWS: https://da-data.blogspot.com/2014/08/minting-money-with-mone...
> By the 14th of May, we were 45% of the total hashing power on the coin. Things started to get a little exciting
FPGAs would be that on steroids. There are way fewer Verilog / FPGA engineers. It also would require custom PCBs and hardware engineers to make it all happen. I wouldn't even know who to ask to design an Hybrid Memory Cube interposer and to fit it on an FPGA for example.
