In 2013, when the same party was in power, SERPRO was tasked with replacing Microsoft in key aspects, such as government email (which was handled by Outlook Server at that time) and operating systems.
The main reason was fear of espionage. So, in reality, we are more afraid of the US spying on us than random internet dissidents.
Maybe if I was in government I would think the same. Catch criminals before they act, stuff like that (I'm just being the devil's advocate here).
This is a dillema, and the worst kind. The kind citizens know nothing about, so the only possible way to talk about it is to speculate. I am, however, too old to speculate about these things anymore.
Why bake it into everybody else's Windows? If you make say a Brazil Government-only Windows which trusts this CA instead, I guarantee somebody crucial in Brazil will buy a 3rd party Windows laptop independently and it doesn't work with this CA's certificates and that ends up as Microsoft's problem to fix, so, easier to just have every Windows device trust the CA.
They'll have an assurance from the CA that it won't do this sort of crap, and that's enough, plausible deniability. Microsoft will say they take this "very seriously" and do nothing and it'll blow over. After all this stuff happened before and it'll happen again, and Windows will remain very popular.
(Although I'm not sure why "Netraft confirms, Windows is dying" is a useful comment here anyway. Windows is a behemoth.)
There's a clear but slow trend on desktop.
Jan 2009: 95.4% Windows
Jan 2016: 85.2% Windows
Jan 2024: 73.0% Windows
In e.g. US it's going down faster, desktop market share now at 62%:
https://gs.statcounter.com/os-market-share/desktop/united-st...
Large enterprises in the US generally have the same capability, but not loaded into operating systems by default (that is: Walmart's ability to do this on its own network in no way impacts you, who have never worked on that network).
The big CA have their own "Boy club". See Ahmed used cars and certificates.
That CA is not used for much else and is basically confined to our state. But it has to be in Windows, otherwise no other software could verify the signatures.
See eIDAS and other similar schemes.
Ukraine for example successfully operates their own eIDAS-like scheme where everything is based on DSTU+GOST algos not supported by any operating systems a major libraries, the certs are signed by the government root and it doesn't leak into web pki.
Google, Facebook, Microsoft, Apple, Cloudfare, Godaddy, Lets encrypt. They all "work with Microsoft".
Imagine if you don't have a state CA, and your relationship with the USA goes sour, and the USA prohibits all of their major CAs from doing business with your country, including Let's Encrypt. People in your country still use the internet and you still want to protect them from scammers pretending to be local businesses online. So it's important that you as the state can provide CA services and sign those certificates yourself.
Of course, in this scenario you wouldn't want to be relying on Microsoft to help. But the general principle is that any state who can afford it has a strategic interest in having fully self-sufficient Internet infrastructure, including DNS, CAs, IP allocation etc.
Most certificate trust stores have some certs in them that are sketchy, eg a bunch of university certs from all over Europe. These are slowly dropping off, presumably because it costs quite a bit to operate a CA in a compliant fashion and get it professionally audited.
Issuing a fake cert is grounds for removal from every certificate trust program I’m aware of, if it can’t be demonstrated that they found what went wrong and have fixed it so it can never happen again.
[domain name typo fixed]
Chrome, which is both the cert store and the client on certain OSs, might implement this limited trust. But Windows can't, except maybe for its own internal services.
Either way, this makes little sense overall. If a CA is trustable, it can be trusted to sign a certificate for any domain. And if it's not trustable, then you can't trust it for any domain. Brazilian companies wishing to use a local CA can own .com domain names, so you'd be preventing a completely legitimate use case. Google almost certainly has a google.br domain, so if the Brazil CA is untrustworthy, they can still be used to attack Google even if you only trust them for .br domain.
That's a silly position to take.
When I lived with roommates, I trusted them. But I also locked my bedroom when I went out. Because there's no good reason to rely on trust when you don't have to.
It would be like restricting trust in a CA to certificates for sites whose name starts with a certain letter. It's exactly as meaningful from a Web PKI perspective.
Could Microsoft make it so that Windows only trusts this CA for certificates on domains whose name starts with a "b"? Sure. Would it help with anything? No. Would it be actively harmful to companies whose name starts with A that are using this CA? Yes. The same thing is true for domains whose name ends in .br.
I researched the issue a little here: https://alexsci.com/blog/name-non-constraint/
Would it be fair during that time if I asked you to hold your PRs, bug tickets and work in general because we're on paid leave?
On-call rotation exists for those reasons. Otherwise, all countries would need to respect all other countries holidays.
In fact, we're not even aware of most US holidays. It is likely to be a coincidence.
Yes. That's completely normal for companies that do business with Brazil.
In fact, your example is perfect. We're not talking about business. CAs are different.
In security and infrastructure, there's always someone working on holidays. The larger the organization, higher are the chances that some kind of rotation exists.
There are whole startups designed to solve this, like PagerDuty.
I am now very curious to understand where your question comes from. There must be some misunderstanding here. You never went on-call or seen a friend do it?
Red herring [1].
OP said it’s malicious or incompetent to release this on a U.S. holiday weekend. You asked if similar consideration would be given to Brazil. Multiple people chimed in that it would. You’re now pivoting to on-call capacity.
Any amount of on-call capacity can be saturated. That’s why competent multinationals avoid releasing while markets they’re likely to impact are sleeping or drunk. This is a high-level scheduling operation, however, so it’s reasonable for those lower in the organisation to be unaware why an update is being pushed next Tuesday instead of this.
Rotations exist, specially in large organizations, or when there's shared responsibility.
Now we're talking nonsense about "you said, he said", this conversation makes no sense. I am much less invested in this than you think.
Straw man [1]. Nobody claimed otherwise.
Rotation or always-on isn’t a substitute for being aware of your customers. Good culture permeate this throughout the organisation. Competent ones have someone at the top ensuring controls are followed.
Can you explain the point you made precisely, in the context of the original subject?
You’re not. Someone above you should be. Otherwise that’s incompetence.
What I’m attempting to refer to, is that _if_ this was done with malicious intent, then maybe the hope was that doing it during a holiday would reduce response time or allow it to fly under the radar. Of course, as you say, just because it was a holiday does not inherently mean it’s malicious, it has plausible deniability.
I don't know if there's a rotation or another system. I think there are probably multiple across different parties responsible for maintaining CA trust.
A MitM attack can be easily carried out by someone in control of an ISP, or someone in control of a WiFi network. So, if you trust your ISP and your WiFi network, realistically you have nothing to worry about.
The reason that this issued certificate could allow an attack like this to happen is because all websites nowadays use HTTPS connections, and certificate authorities are the entities that tell your web browser that certain certificates are legit. They confirm that a website is actually that website.
If you visit some website and someone tries to do a MitM attack between your web browser and that website, the web page should fail to load because if they try to change the certificate, your web browser should reject it because it is invalid.
The bad certificate was caught, and caught quickly. The system works.
It is a bit like if airport security catches someone who wanted to bomb a plane. Yes the immediate gut reaction is that is terrible, but if you think about it for a bit its actually reassuring, since its proof the safe guards worked.
Microsoft have a terrible reputation for security, which they've earned through doing stuff like this.
It's not likely to get any better any time soon either, as their trajectory is still pointed downwards.
They have one of the largest cyber security operations worldwide and regularly track and dismantle criminal operations. There's some great people working there.
Then there's Azure. Which is used by large organizations and you would expect it to have the utmost care when it comes to security. But it often does badly, in several instances it allowed different tenants to access information from one another, something unheard of on AWS. For example: https://www.securityweek.com/microsoft-patches-azure-cross-t... or https://www.theregister.com/2024/06/05/tenable_azure_flaw/ or https://borncity.com/win/2023/08/03/microsoft-as-a-security-...
There are so many cross tenant vulnerabilities that there could be some overlap in those URLs, and it's a bit late at night for me to read those carefully, but you get the idea.
They do get the most flak about Windows, which used to be a non networked, single user OS.
If the whole value is in ticking the box, why would that develop a culture that values anything more than the tick?
Unfortunately, it's true. People used to relying on Microsoft understandably don't want it to be so, so they're in for a rough time trying to figure out actually workable alternatives. :(
This has been an ongoing problem for years, and every time some new problem is found Microsoft just trots out the PR promises that they'll do better. Without then doing any better.
• https://arstechnica.com/information-technology/2022/10/how-a... (2022)
• https://arstechnica.com/security/2023/08/microsoft-cloud-sec... (2023)
• https://arstechnica.com/information-technology/2024/04/micro... (2024)
For the US government's official perspective on Microsoft's security competence, there's the federal Cyber Safety Review Board report released in April this year:
• https://www.cisa.gov/sites/default/files/2024-04/CSRB_Review... (2024)
"Throughout this review, the board identified a series of
Microsoft operational and strategic decisions that collectively
points to a corporate culture that deprioritized both enterprise
security investments and rigorous risk management," the report
reads.
Note that the problems didn't start in 2022, that's just the earliest I could be bothered looking with minimal effort. ;)
They may be good when luring in customers, but once thats done, they don't give a fuck about anything but their current cash flow. And the fact that ultra-big players can ask them for customized OS distribution that has this turned off (just like my own mega corporation) doesn't change anything on statements above.
A customer can take an unlogged cert, log it themselves, and then use the certificate and the separate proof of logging they received and use that just fine. Google have some services which do this. One clever thing this enables is you can buy the cert secret-product-name.example, unlogged, build the web site, check everything works, and log the certificate seconds before the product launch event, so snoops can't tell your new product is secret-product-name until the moment you announce it, yet the site works immediately. I have very rarely seen this done but it's possible. When there's an ordinary White House transition process both plausible transition site certs get logged, even though in practice one of those sites is never published. Since Trump I have no idea if this process is so smooth any more.
A CA can choose whether to have this "issue unlogged certs" process as something they offer, it's a niche thing, but it could make sense. They need to keep adequate records of every certificate they issue (that's required) and logging is a very easy way to satisfy that requirement, but it's not the only way.
In practice, the logged certificates are the easy consumer option, like selling ready-to-eat food in a deli. Some customers might be prepared to buy ingredients and go away to make food, but, many customers probably want to eat food immediately so for extra money you sell products that can just be eaten immediately. So, yes, the vast majority of certificates issued every day are indeed logged immediately so as to provide the product people want.
If only there was a way to monitor company equipment without issuing a cert for a public 3rd party.
I don't know that's what happened here, though; there are malicious possible explanations!
This isn't too different from the argument that (I believe reasonably) applies for how a company has the right to monitor employees, but I think many people are opposed to even democratic governments monitoring people and would consider such use malicious.
So a government monitoring its employees is one step closer even than a company, since it's the same organization in this case (though again, I think it's largely reasonable for a government to monitor their employees).
Or to redirect to an internal, no doubt pitched as more secure, search engine.
https://security.googleblog.com/2013/12/further-improving-di...
https://security.googleblog.com/2015/03/maintaining-digital-...
So an employee can type in google.com and check any boxes about did you verify this is the correct name and it's OK to issue, and then they hit issue and the certificate is minted, just like that.
Why google.com? Well, if you're testing something, say a web browser, what web site comes to mind? Maybe google.com? Doesn't work. Oh - the cable is unplugged. Doesn't work. Wait, this checkbox isn't checked, try again. Aha, now it works... Oops we issued a certificate for google.com
This is a "Never" event, there should be countless things in place to ensure it doesn't happen. In practice, just like safety guards on dangerous machinery, too many people just can't be bothered with safety, it's a cultural issue.
† Let's Encrypt famously does not. As part of the Mozilla application process they need to show their certificates expire properly, usually people either manually issue a back-dated certificate which has expired already, or they manually issue one with a deliberately short lifetime to expire. Since they can't issue manually Let's Encrypt obtained an ordinary certificate from their own service and then waited ninety days for it to expire like a fucking boss.
If a CA can be convinced to issue a server certificate for google.com, would you feel very comfortable trusting their contract/deed/... signing certificates?
The brower (possibly only edge) and system would show the connection as being secure.
And without DNS pointing google.com to that IP address, it's pretty useless.
If they were issued for IP addresses they would have to reissue the certificate every time they spun up a new server. Also it's why if you spin up another server and make DNS point google.com to that server, it would not pass verification since the certificate you will be using on that server is not issued to *.google.com, but rather some other domain you own. The IP address plays no role in certificates.
The Subject field is not consulted so long as the SAN field is present, and can in theory be any X.500 Distinguished Name, of which Common Name is one possible attribute, which may be any freeform string of a limited length (though it is typically set to the primary domain the cert is issued for, for easy identification).
On the internet itself maybe, but you can still MITM people on some network, right?
The "blast radius" is limited to Microsoft since they are the only ones that trust this particular certificate authority. Your non-Microsoft browser won't trust these certs. Your non-Microsoft OS, Java program, etc. etc. won't trust these certs.
But even before they switched to this "Chrome Root Program", they have distrusted specific CAs, for example Symantec in 2017. https://security.googleblog.com/2017/09/chromes-plan-to-dist...
Admittedly DNSSEC has issues to put it mildly, but it does serve as a counterexample to your claim.
I think the parent is suggesting that users should be able to tune their trust stores. I'd imagine that trusting only the CAs that are in all the major trust stores (Google, Microsoft, Mozilla, and Apple) would be a reasonable policy. Few websites would choose a CA that falls outside that group.
The hard part is getting the people you want to establish a trust relationship with to give you a copy of their key. Web of Trust was the answer to logistical key distribution problem. The idea being there would be an organization that would vet people and vouchsafe their cryptographic material for everyone else.
The problem of course, is that the more invisible this is to users, and the more unintuitive the actual mechanics, the more valuable cracking the CA's becomes for hostile actors because of the ensuing blast radius compared to the boast radius that would result from theoretically getting the practice of key exchange in the public, and getting them to internalize the act of creating their own trust networks.
Of course, if you have dreams or fantasies of being able to control people, none of the work that goes into educating the populace is ever going to be endorsed, because once everyone realizes that they can at least assure their own safety by not delegating their cryptography, the entire idea of eacesdropping as a third-party by tapping the line is unmade. Which is not a popular state of affairs universally.
However, if you don't trust the inclusive nature of Microsoft's trust store and prefer Chrome's, there should be a tool to swap out trust stores. I don't think such a tool exists yet.
- Accept any certs trusted by Bruce Schneier unless they are not trusted by tptacec
- Do not accept new certs for top 1000 domain names unless they are over 7 days old and trusted by the Mozlla Foundation
Various experts could create the rules they use to decide which certs or CAs they trust and users could decide which high profile authority figures or institutions they want to trust. One example might even be "Bruce Schneier paranoid version"
I think this doesn't exist because of the following:
1) technically it is possible to do it today with the existing tools, even though nobody does it
2) the negative impact of trusting certs one shouldn't is low for the average user
3) sophisticated users already take precautions and are rarely fooled
I think for something like this to work it would have to be extremely simple. Surely there would be the same phenomenon as "Dr. Oz" in the realm of cyber secruity. Maybe the 'Kevin Rose settings" would be popular, etc. But that would still open the door to distributed trust which is an improvement over blanket trust of large corporate entities.
The problem is between the keyboard and the chair. Users struggle to understand SSL already. Browsers decided that the distinctions between EV, DV, and OV were too complex and hid them. What will your grandmother think when she opens up her bank and your browser plugin shows a greenish yellow trust indicator because the cert is trusted by Google, Apple, and Microsoft, but not Mozilla?
Unfortunately, trust is binary. Your grandmother click on the bank bookmark and either sees her banking websites or sees a scary warning.
This is pretty bad. Someone circunvented the ban on emitting public certificates but also disrespected Google's CAA rules. Hope this CA gets banned on Microsoft OSes for good.
I'm not a Windows user, but I have to wonder if there's a way to use the Chrome trust store on Windows/Edge. I can't imagine trusting Microsoft's list.
> Microsoft seems to be casual about trusting CAs
Are you aware of the big hack on Netherlands govt-approved CA? Read about: DigiNotar. My point: That was a widely trusted CA that was hacked after the root CA cert was added to most browsers / OSes trust stores. So would you say that MSFT was "casual" about trusting DigiNotar root CA? How about Mozilla Firefox? I doubt it.
A challenge for Microsoft is that they aren't transparent in their inclusion decisions, so we can only speculate why they chose to trust this CA. What gives you confidence that Microsoft is doing careful vetting?
In stark contrast, Mozilla publicly and extensively documented why they didn't trust this CA [2].
I'm sure that Microsoft carefully ensure they're paid for all CA additions.
Given their monopoly there is no incentive for vetting.
For these government CAs my expectation is that they're a sort of quid pro quo and (wrongly) not seen as a security problem.
I don't see any reproducible builds for Microsoft Edge. Therefore, your statement is an assumption and nothing more. We can not trust Microsoft more because they are more proprietary.
I don't think those two things have anything to do with each other. Living in Redmond for my entire life has mostly shown me that MS owns one of the best and most lucrative sales orgs and sales channels in the world. That sales channel means they can sell to governments better than nearly anyone one the planet, no matter what their security practices are like.
Are you? Why? For Mozilla the vetting process takes place in public, that's one purpose of m.d.s.policy so we can see what is or is not done and draw our own conclusions.
Each of the proprietary trust stores has an opaque process which unless you're a CA applicant you don't even know what they're asking for, much less what (if anything) they do with it.
These are for-profit companies, and this is a cost centre. The cheapest possible thing they could do is piggy back entirely on the public Mozilla process (which of course for this CA would mean rejecting)
The next cheapest option would be to allow senior management to override Mozilla's decisions for, you know, commercial reasons.
And yes, it would certainly be possible for them to have their own teams every bit as effective as the public process but entirely made up of employees and contractors. Weirdly though, although it's easy to run into people who worked for say, the Windows OS team, or XBox team, or Azure team, you don't run into ex-Microsoft opaque CA process people. One reason might be that they're all career professionals, never leave, never get downsized, maybe there are dozens of them. But the more likely reason is they do not exist.
Is anybody else surprised at this point?
Multiple RCEs and critical CVEs cannot be fixed because Microsoft "lost" the source code. So they disclosed those RCEs but without any solution or fix.
(Not kidding, sadly, look it up, there also have been occasional binary patches because of the same reason)
I remember some Windows Fax Service related CVEs and some Wi-Fi drivers that couldn't be fixed directly, too, but don't remember the CVE or whether that was related to the Broadcom driver/module sideloading fuckup.
> The link you gave just gives me a long list of patches.
The link I gave you is the only disclosure/advisory page that Microsoft offers, don't blame me for them not offering a better UI. Ask them to do better.
- https://nvd.nist.gov/vuln/detail/CVE-2017-11882
- https://blog.0patch.com/2017/11/did-microsoft-just-manually-...
- https://cert.europa.eu/publications/security-advisories/2022...
Your own sources indicate CVE-2017-11882 was fixed in November of 2017. The title of the blob.0patch.com article is
> Did Microsoft Just Manually Patch Their Equation Editor Executable? Why Yes, Yes They Did. (CVE-2017-11882)
clearly indicating that Microsoft fixed the issue, contrary to your statement that they 'weren't actually fixed". The body content is consistent.
> NTLM relay attack
NTLM is bad, no question. It's based on a bad threat model - it assumes network admins can secure their corporate networks. Microsoft also fixed most of the issues in NTLM with NTLMv2 back in the Windows Vista and Windows 7 era. And Microsoft announced they will disable all NTLM versions by default within the Win11 lifetime. The biggest problem (unsurprisingly) is non-Microsoft software which has hardcoded the use of NTLM. It's fair to criticize Microsoft here for making available a technology that required so much from corporate network admins and leaving it available (and with use in Microsoft products) for so many years. At the same time, it's misleading to characterize these problems as "weren't actually fixed" - concrete issues with NTLM within its security model _were_ fixed and new technologies were created with better security models.
- https://techcommunity.microsoft.com/blog/windows-itpro-blog/...
> The link I gave you is the only disclosure/advisory page that Microsoft offers, don't blame me for them not offering a better UI. Ask them to do better.
You're mistaken. Microsoft has deep links for each CVE.
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
I'll just leave this here, a month old (Oct 2024) because you seem to critize my old examples [1]. You can also google for "malware NTLM relay attack" and you'll find plenty of other examples.
PS: I also want to add that I won't collect 100s of CVEs for some random person online. I got better things to do than to convince people to ditch Windows. If you want a dossier and analysis, pay us and we'll make a contract for it.
If you want a better vulnerability database, we'll have that available as a product :)
[1] https://www.bleepingcomputer.com/news/security/exploit-relea...
still not incompetence if what they gain from it is bigger than what their customers lose, unfortunately.
[1] https://alexsci.com/blog/ca-trust/#government-control-of-cas
The system is deeply flawed, which is something I realized fifteen years ago when I was put into a situation where I had to use online banking. (Had to being the nearest branch of any bank was an hour long flight away, though there was an ice road you could use in the winter.) One of my first questions of the bank was: who issued their certificate. They didn't have a clue what I was talking about. I suppose I could have pushed the question until I found someone who did know, but I also realized that a random person asking about security would be flagged as suspicious. The whole process was based upon blind trust. Not just trust in the browser vendors to limit themselves to reputable CA, but of the CAs themselves and their procedures/policies, and who knows what else.
…what did the certificate say?
> whole process was based upon blind trust
If I offer someone a ride and they start quizzing me on what differential I’m driving, I’m going to ignore them. That isn’t requiring blind trust, it’s just the wrong place and way to get the information you’re asking for.
When I was in schooling getting filled in on Web of Trust, I about ground that particular day's class to a halt because I couldn't imagine the world was that cavalier on such a thing.
Lo and behold, I realized shortly afterward it absolutely was the case, and there was nada I could do to change it except figure out how to get normal people universally fluent and invested in basic cryptography so they could manage their own trust networks. You can imagine how well that's gone.
I'm critising OP for castiglating a bank employee for not knowing who their CA is. That's not something a line employee needs to know. And that's not the appropriate way to ask that.
If I want to know who issued HN's certificate, I don't e-mail a YC associate. I look at my browser and see it's Let's Encrypt.
(Assuming certificate pinning doesn’t exist, which was the case 10 years ago and is true now, too)
If the bank is unable to tell me which CA they use through a trusted channel, the only way I could tell if there is a problem is if the CA changes.
ie: Brazilian government demands Microsoft to grant them MITM access from Windows machines, in order for the right to do business in the country.
Governments are usually sneaky with their evil plans. It is simply too hard to get away with something like that to make it a viable. Case in point, the fact you are reading about it on hn.
Right now, a CA can issue a certificate for any public key and domain they like. A rogue trusted CA can intercept all traffic.
If a certificate also included a signature by the owner of the public key signed by the CA (using their private key, signed over the CA signature), then a CA would no longer have this ability.
What am I missing?
Infrastructure and processes for key distribution and revocation. Reusing the existing PKI infrastructure used for CA trust roots won't handle it. Perhaps public keys/certs could be distributed over DNS, like for DANE (or maybe even using DANE)?
Not saying it can't be done, just to point out how it's not trivial and requires buy-in from incumbents across the ecosystem.
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
I like your general idea of improving the status quo by adding decentralized/self-managed trust on top of/alongside the existing centralized PKI. Could be a stepping stone towards something more systematically resilient.
I'm not sure it would make much difference to most of the existing PKI infrastructure though. CAs wouldn't see any difference. For example, currently this is what happens:
1. Owner: generate CSR and send to CA 2. CA: validates owner identity, signs cert and returns cert to owner.
All we would then add is:
3. Owner: signs cert with own private key and uses it.
As far as I can see, the only other changes required would be to clients (so they could reject non owner signed certs), and maybe some revocation stuff.
The chain of trust for all the certificates in your example is established by trusting the rogue CA root certificate. The CA (or a bad actor who misled the CA through real-world fraud) could be the “owner” of the key pair you’re trusting for the second signature.
Yeah, this is after the certificate was issued, and my guess, used.
Also, has anyone tried to look up CT logs lately? I tried. Can get maybe a single FQDN if you look, but trying to do wildcards or name-alikes, nothing worked. Most of the CT searching websites were straight up broken. Clearly nobody is actually looking at CT logs.
CAs are a joke. There's a dozen different ways to exploit them, they are exploited, and we only find out after the fact, if it's a famous enough domain.
We could fix it but nobody gives a shit. Just apathy and BAU.
We really can't fix it. You try and coordinate updates across all major (and most minor, and outdated) OSs, and websites around the world, amateur & professional, from the mom-and-pop store who don't understand any of this, to the big bank that'll take 3 years of procedure.
I have friends who work in the CA field (on the OS side). The level of alcoholism and turnover in the field is... higher than average.
crt.sh allows you to subscribe to an RSS feed for wildcard searches. We map those into a slack channel for infrastructure advisory alerts. You can also setup more aggressive alerts if something shows up unexpectedly.
It's an incredibly handy service.
1. https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...