If you set it to a more compatible mode and accept both, the malware could simply strip the payment protocol and pretend the merchant doesn't support it and request that you pay using the plain old Bitcoin protocol.
Hey, that's an interesting question, not really related to Trezor but to the payment protocol itself.
If you request a https page and receive a http one, your browser can clearly detect something's not right.
But how does that work with PaymentRequests? AFAIK they're pushed by the payee, not requested by the payer, right? What if a malware sees that an authenticated payment request is passing buy, and simply replace it by an non-authenticated one? If you know the merchant is supposed to send you an authenticated payment request, you'll realize there's something wrong. But can we really expect people to understand this?
... don't dig too far down with this kind thinking, it's turtles all the way and then there is .... yes CA's
CA's don't help at all, even if they want you make believe it, but indeed it's a lie proven to be wrong..
(nevertheless the myth of protection through SSL CAs remains alive)
Feb' 13
(...)
Well, we just spotted a new malware sample (Brazilian banking/password stealer) which happens to be signed with a real and valid digital certificate issued by DigiCert
(...)
Misusing Digital Certificates
In the recent years, the PKI environment within which digital certificates are created, maintained and used began showing its weaknesses. We’ve witnessed several ways in which the certs have been misused in attacks on individuals, enterprises and government organizations:
Stolen code-signing certificates and the associated private keys were used to sign malicious software. For instance, a breach at the security firm Bit9 allowed attackers to steal one of the company’s certs and use it to distribute malware. An apparently-stolen cert was used to sign a malicious Java applet. An attack on the browser company Opera allowed the intruder to access a code-signing cert and use it to sign malware. Code-signing certs stolen from Adobe were used to sign malicious software. It’s not uncommon for malware to be programmed to capture victims’ code-signing and other certificates, which will ensure that we’ll see more incidents of stolen certificates being misused.
CAs issued weak or improper certificates, which were later used in attacks. For example, DigiCert mistakenly sold a certificate to a company that didn’t actually exist; the cert was used to sign a malicious executable. Another CA named Digicert Sdn (no relation to DigiCert), issued certs with weak “512-bit RSA keys and missing certificate extensions,” according to its parent company Entrust. Later, two of the certs “were used to sign malware used in a spear phishing attack against another Asian certificate authority.” In another blunder, a CA named TURKTRUST mistakenly issued certs that have led to the impersonation of Google’s servers.
Man-in-the-middle (MITM) attacks abused certificates to intercept SSL/TLS traffic. Software rarely complains when a server’s SSL/TLS certificate has been signed by a trusted, but unexpected CA. For example, one person noticed that when connecting to Gmail via IMAP/SSL from a hotel, the server’s certificate was signed by an entity other than Google. A similar technique was allegedly used by Nokia, presumably for legitimate purposes, to decrypt phones’ HTTPS activities. There are probably many MITM instances where the traffic was captured illegitimately; unfortunately, such situations are often hard to detect.
Malware installed illegitimate certificates, configuring infected systems to trust them. For instance, a malicious Browser Helper Object (BHO) installed a fake Verisign cert as a Trusted Root Certificate Authority after infecting the system to eliminate security warnings. In another example, spyware acted as a local proxy for SSL/TLS traffic and installed a rogue certificate to conceal this behavior. Installing a fake root CA certificate on the compromised system can also assist with phishing scams, because they allow the attacker to set up a fake domain that uses SSL/TLS and passes certificate validation steps.
These were just some examples of real-world incidents where digital certificates were misused. In a follow-up post, I discuss the initiatives aimed at strengthening the PKI ecosystem within which the certificates are issued, validated and utilized. Read on.
and there is a lot of router harware able to incept SSL btw, so Man-in-the-middle -like it's mentioned above in the hotel example when connection to gmail- is not unusual but quite common
) and change all Bitcoin addresses to the ones of the attacker. If anyone is interested, I could probably write one as a proof of concept.
