Issue metadata
Sign in to add a comment
|
Emergent conditions enable HPKP-centric ransomware
Reported by
bry...@zadegan.net,
Jun 16 2016
|
||||||||||||||||||||||
Issue descriptionNOTE: Creating this ticket per automated request from security@google.com. Please understand that our strongest preference is for discussion surrounding resolution to take place among the originally contacted parties in order to coordinate the response as this is the result of multiple defects across multiple implementations. Please grant ryan@cyph.com with access to this report as a secondary reporter of this issue. Email body follows. --- To: vulnerabilities@eff.org, security@letsencrypt.org, security@mozilla.org, security@google.com, hacker@linux.com From: bryant@zadegan.net Subject: [High] An intercepting party can guess the topic just from metadata. All concerned, What we're describing below is not a single specific vulnerability but rather an aggregate vulnerability arising from a combination of otherwise-low or informational findings which enable a massively potent new attack vector. Please note that the timeframe on this report is limited mostly due to a self-imposed requirement on our end to thoroughly validate the novel attack pattern described in this report. Due to the fact that this is the centerpiece for the Black Hat/DEF CON talk "Abusing Bleeding Edge Web Standards for AppSec Glory," disclosure takes place either on August 3rd or August 4th depending on the schedule imposed by Black Hat. A succinct list of low-ranked defects or informational observations which enable this potent attack pattern are as follows: --- Let's Encrypt blindly trusts that the machine requesting the certificate is doing so with human authorization. This is the easiest to mitigate and is what currently most effectively enables this attack. --- Let's Encrypt inconsistently applies rate limiting to certificate generation. This was only just confirmed+reproduced and is the only finding we will submit in a subsequent report. --- Let's Encrypt's actual rate limiting is insufficient to restrict the damage potential posed by this attack. --- HPKP max-max-age at one year in Firefox allows for an effective ransoming of Firefox users. --- HPKP persistence in Chrome's Incognito and Firefox's Private Browsing modes in violation of privacy-centric threat models for these modes gives users no mechanism for avoiding an HPKP lock-out (what we're calling HPKP Suicide™) short of manually clearing keys or reinstalling the browser, something most lay users will never figure out. --- The HPKP specification does not seem to suggest (let alone require) additional verification of a request to enable HPKP. In turn, both Chrome and Firefox blindly trust that HPKP headers have been issued with the authorization of site owners. Cheers, -Bryant Zadegan and Ryan Lester keybase.io/bryant keybase.io/ryanlester ---------------------- Vulnerability Details: ---------------------- Upon compromising a targeted site which may not already have HPKP enabled, an attacker can, through rapid key rotation enabled by a supported CA (such as Let's Encrypt), hold access to a site by a vast number of users up for ransom. In more detail: essentially, emergent conditions arising from the existence of HPKP and a novel mechanism for producing trusted certificates (Let's Encrypt, henceforth LE) enables a new class of ransomware. Specifically, malware infecting a web server can successfully leverage LE and HPKP in order to hold users of a site up for ransom, meaning that vast quantities of visitors to a website (on the order of millions of uniques) may be denied access for as little as 60 days and as long as a year until the targeted site pays a ransom to retrieve the master key. The low-to-informational findings enumerated in the introductory section are sufficient to summarize some of the architectural decisions through which this vulnerability emerged. We've seen conversation and speculation about this topic arise spontaneously on numerous forums such as Hacker News (e.g. https://news.ycombinator.com/item?id=11679887), and the authors of the HPKP specification even discuss hostile pinning in the context of naïve denial of service (https://tools.ietf.org/html/rfc7469#section-4.5), but we've never seen anybody identify these final steps required to successfully weaponize this as a persistent attack. The missing component that nobody seems to have designed involves the use of rapid key rotation to rotate disposable keys while pinning a recovery key, something which can currently be accomplished quite successfully via LE and very much in spite of LE's use of rate limiting. In the future and as anonymous cryptocurrencies take off, we anticipate that providers of paid certificates with little to no significant rate limiting enabled will be usable in implementing this attack in place of using LE. It is for this reason that we've also included the Google and Mozilla security teams on this report, though we believe the initial mitigation priority rests with LE. In its own right, this aggregate vulnerability is not of critical severity due to the need for a machine compromise to enable the described attack. However, both its nature as a novel attack pattern arising from a combination of architectural and implementation-specific compromises in the current SSL/TLS landscape as well as the imminent financial damage enabled by this attack are what justify high severity as well as a need for a resolution by committee, specifically the committee included on this thread at a minimum. Reproduction steps for the attack pattern (which we're dubbing RansomPKP in the spirit of unnecessarily naming security issues) can be found below. --------------------------------------------- RansomPKP Reproduction Steps / What Happened: --------------------------------------------- 1) Determine your target. 2) Generate a fixed keypair from a machine not affiliated with your target (what we're calling a Ransom keypair). 3) Take control of the target web server and include a payload that will accomplish the following steps. Include the Ransom public key hash with the payload. 4) From the targeted web server, generate the first of a rotating keypair + CSR (what we're calling a Lockout keypair). 5) Follow the ransom lockout process (see subsequent steps for the ransom lockout process below). This step may loop. 6) Receive payment for Ransom keypair and disclose Ransom keypair to the target, ending the attack. The ransom lockout process: While the number of users for whom HPKP headers are set is less than *n* (a value to be determined by the attacker's research for the given target), 1) Install (or assure the presence of already-installed) HPKP headers containing the Ransom and Lockout key hashes. Set Max Age to one year. 2) If the number of users who've received the headers reaches *n*, 2a) Generate new Lockout keypair + CSR. 2b) Send CSR to LE for certificate generation. 2c) Update TLS certificate and HPKP header with new Lockout key and key hash. Note: depending on the target, this process may be modified such that the payload maintains stealth for as long as possible prior to the *initial* rotation of keys. This ensures maximum coverage of users who will be locked out before the target detects the attack. The moment the key is rotated the first time, it's assumed that the clock on resolution begins counting down as the initial reports of a TLS error will likely overwhelm the target's support staff. ------------- Version info: ------------- Chrome 51.0.2704.84 Stable Firefox 47 LE Client (Certbot): 0.8.1 -------------------------- What should have happened: -------------------------- We frankly don't know. As stated earlier, this vulnerability appears to be an emergent property of HPKP and new, free certificate authorities such as LE. However, as paid CAs continue to catch up and eventually add features such as rapid key rotation, this will soon be a much more common problem. Because of this, this should be mitigated before this becomes not just a viable class of attack (as it already is) but a common one. On technical merits alone, this would normally be considered moderate severity. However, considering that this opens a new vector for extremely potent ransomware, we're of the position that business impact upgrades the severity. Additionally, we're slated to disclose this finding at the following talk to be presented at both Black Hat and DEF CON: "Abusing Bleeding Edge Web Standards for AppSec Glory". This puts the earliest release date as either August 3rd or 4th. ---------------------------------------------------------- Existing Mitigations, Strategies, and Counter-Mitigations: ---------------------------------------------------------- To begin: This attack pattern is a non-starter without some mechanism to infect the target. However, once the target has been compromised, this strategy can be used to quickly and effectively extort thousands of dollars. Touching on specific mitigations present in affected technologies: The Chrome team has implemented a max-max-age of 60 days on HPKP. This inadvertently also reduced the impact of this vulnerability considerably for users of Chrome given that users of Chrome will now only be potentially ransomed for no longer than 60 days as of the version of Chrome (51) noted in this report. This is in reference to the following issue: https://bugs.chromium.org/p/chromium/issues/detail?id=523654 Furthermore, it's understood that a victim may counteract the attack by publicizing remediation steps on various social media platforms, etc. to clear the ransom state for its users. We'll discuss in Aggravating Factors why this might not be effective. Finally, one suggested mitigation made within the HPKP spec itself (https://tools.ietf.org/html/rfc7469#section-4.5) is the use of Certificate Transparency (https://tools.ietf.org/html/rfc6962). This may potentially work in discovering attacks should an interested party be actively monitoring certificate transparency logs (per https://tools.ietf.org/html/rfc6962#section-7.2), but this may not be effective at mitigating attacks against high-traffic properties timeboxed within, for instance, a 24 hour window. -------------------- Aggravating Factors: -------------------- Both Chrome and Firefox enforce HPKP in Incognito/Private Browsing modes in _blatant violation_ of the privacy-first threat model for Incognito/Private Browsing modes. In doing so, it's worth noting that site lock-outs and ransoms will persist even when lay users switch to Incognito. This references Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=1242226, previously opened by Ryan Lester. Speaking to publicizing remediation steps to a general audience: a tactically priced ransom may make payment of the ransom more cost effective than attempting to teach lay users how to reset their list of pinned keys, so we anticipate that RansomPKP attacks charging no more than a few dozen thousand dollars for a wide spread of large targets will still succeed. In the course of a more thorough attack where interfaces with the general public are also disabled, an attacker may be able to extort orders of magnitude more from the target. Finally, LE inconsistently handles rate limiting, but even with rate limiting in place, the fact that 20 certificates can still be issued per week for a given domain makes this attack extremely potent. -------------------- Potential Solutions: -------------------- In short: there needs to be a better long-term process for validating whether a domain has been enrolled for LE. Likewise, changes should be considered to HPKP implementations, such as universal adoption of 60 day max-max-age (currently in place with Chrome) as well as the banishment of--or potential to bypass via user action--HPKP in Incognito/Private Browsing modes. Immediate correction: allowing sites to opt out of LE should mitigate the risk to major properties or to properties which explicitly wish not to use LE certificates in the short term. Additionally, dropping rate limiting to only a handful per week, if not only one per week or even one per month, may be enough to mitigate risks posed to larger institutions with better detection capabilities. It may be worth requiring an extra step of authentication to enable the current rate limits on key rotation. In depth: While this issue can be handled in a number of ways, the following is the most conservative mitigation proposal we were able to come up with, with particular emphasis on keeping UX changes and implementation work on LE/EFF's part to a minimum: 1. Leverage DNS as proof that the true owner of any given domain actually wants a LE certificate. Simplest approach would be to require some arbitrary global constant in a TXT record for every domain included in a cert request, e.g. "LETS_ENCRYPT". With this, an attacker can't start generating a fresh LE cert for a website they don't own just by compromising the box; they'd also need control of its DNS. 2. For additional assurance, allow anyone to explicitly blacklist their domain from LE. This could be done with a command like `certbot blacklist -d cyph.com --email ryan@cyph.com`. On LE's end, this blacklist would just be a server-side list of domains with associated email addresses. If a cert with a blacklisted domain included were ever requested, it would be automatically rejected. — a. To remove a domain from the blacklist (`blacklist --remove`?), a confirmation link received via email would have to be clicked. The user initiating the blacklist reversal would have the option to receive the link at 1) the originally specified recovery address, 2) the admin address specified in the domain's whois info, or 3) any of a small set of predefined constants (e.g. letsencrypt@cyph.com and security@cyph.com). — b. See 3(b). 3. Make the following changes to the registration/recovery contact email address logic: — a. If you aren't willing to disable `--register-unsafely-without-email` entirely, at least highly discourage it (more so than you already are) with a big scary warning about the RansomPKP risk. — b. Check IP addresses of A and MX records for the address hostname; if there's a match, reject it and have certbot display an explanation that using an email account hosted on the same machine as the web server effectively circumvents LE's 2FA requirement and opens them up to a new class of ransomware (we can provide a link to include for more info on RansomPKP post-disclosure). 4. Add in a configurable cancellation window / time delay for cert generation (default to maybe a day or so?), with logic in the timing of automated renewals to account for whatever that delay is set to. When a certificate is requested for an FQDN whose root domain has already had itself or any of its subdomains issued a cert by LE, the previous email address on record for that domain is sent a link to cancel the request. If the cancellation link isn't clicked within the previously specified window, the certificate is issued. — a. There'd be no delay for a cert request wherein every domain included has never previously been issued a cert by LE. 5. Further to #3, it would be ideal (but maybe not necessary) if, after an actual issuance, another email were sent out to the same email address with a link to reverse the issuance (revoke cert on LE's end + blacklist the domain + restore the previous cert on the affected machine). This link should expire at the same time as the previous cert. — a. Not sure whether this is already the case, but it might be helpful for the automated renewals to occur a few days earlier than necessary so as to not make this email seem pointless. Alternatively, only send this email when a cert is issued well before the previous one's expiration date and/or the key pair used changes. ----------------- Bug Report Notes: ----------------- Tim Willis (@google), per request, this should be used to generate a new bug report within the Chrome team. Please put bryant@zadegan.net (Bryant's personal address) as the primary, ryan@cyph.com (Ryan's business address, copied) as the secondary. - Note for the sake of the report that this is a Security issue which requires confidentiality. - Note for the sake of the report that this affects any Chrome build which supports HPKP. Releases prior to 51 are more significantly affected due to the unrestricted max-max-age. Daniel Veditz (@mozilla), this should be reasonably shoehorned into the stub bug which you created, https://bugzilla.mozilla.org/show_bug.cgi?id=1279662. Please add bugzilla@zadegan.net (Bryant's bugzilla-specific alias) for access, with hacker@linux.com (Ryan's personal address) as secondary. - Note for the sake of the report that this is a Security issue which requires confidentiality. - Note for the sake of the report that this affects any Firefox build which supports HPKP. -------------------- Disclosure Timeline: -------------------- This finding will be disclosed as early as August 3rd and as late as August 4th, 2016 given that it's the centerpiece of the talk "Abusing Bleeding Edge Web Standards for AppSec Glory," accepted to both Black Hat and DEF CON this year. Much of our time was spent cementing the validity of the find, but we're now entirely confident that this can be used as described to mount effective ransomware campaigns against sites vulnerable to any variety of traditional injection attacks. We feel that the immediate mitigation of allowing sites to blacklist themselves from LE is a sufficiently simple mitigation to impose within the next 48 days between now and the earliest date of public disclosure.
,
Jun 16 2016
,
Jun 16 2016
Assigning to timwillis and palmer since they have some context. (Tim is OOO today though.)
,
Jun 16 2016
Thanks. If I had to distill this down to the most salient points, I'd say that the most immediate resolution rests with Let's Encrypt, though implementers of HPKP should look to mitigate the risk this pattern poses as a ransomware vector as more CAs enable rapid key rotation and potentially more free CAs with this functionality go live. We don't anticipate a need for a quick fix or other short term mitigation by the Chrome and Firefox teams unless, of course, Let's Encrypt opts to do nothing.
,
Jun 16 2016
,
Jun 16 2016
,
Jun 16 2016
,
Jun 16 2016
,
Jun 16 2016
,
Jun 16 2016
,
Jun 16 2016
,
Jun 17 2016
All on the thread: We have two other discussion threads going on at the same time, one with LE and the other with Mozilla. With regards to LE, there was a proposed simplification of RansomPKP by Jacob Hoffman-Andrews which would rely on establishing a TLS relay on the compromised machine and ending the TLS connection at an attacker-owned endpoint, allowing an attacker to forgo Rapid Key Rotation by maintaining control of just one key (the Ransom key). We've whiteboarded this alternate proposal and believe it's viable, though for a number of reasons which we can enumerate later but which mostly reduce down to the resources needed and resulting ROI, we disagree that this version of the attack is as effective as the RKR version. Still, the point was made that there exist potentially multiple ways to successfully use HPKP to hold a site's userbase for ransom, something not at all considered during the drafting of HPKP beyond a mere DoS via hostile pinning. LE just now concluded with "Wontfix," and although we believe that any number of fixes by LE could substantially reduce the near-term potential for harm enabled by the service (such as dramatically reducing the rate limit, among others listed in the original email), it's within their right to assert that LE won't take action. Since Ryan and I have an attack which clearly works and have no obvious mitigation paths in front of us in light of LE's "Wontfix"... we're out of ideas for mitigating the attack enabled by LE. Thoughts?
,
Jun 17 2016
,
Jun 17 2016
Thanks for taking the time to report this issue. For all of this discussion, let’s keep in mind that the scope of this attack requires an attacker to have already hacked someone. I realise that those contributing to this thread know this, but for others reading this thread without that background, it’s important to remember that this scenario is usually considered “game over” before it really begins, as an attacker would already have unfettered access. Considering that, I would posit that the root problem is not with Let’s Encrypt (LE), but with whatever vulnerability enabled the attacker to compromise the service in the first place. An attacker who can gain administrative control of the service has unlimited ability to damage the service, its users, and the operator's reputation in whatever way the attacker pleases. If an attacker has this type of unfettered access, attempting to extract a ransom via HPKP seems unlikely due to the possibility of significantly more interesting or lucrative alternatives It is true that the existence of HPKP makes it all the more important for site operators to secure their deployments. The problem of hostile pinning — which already includes the idea of pinning a site for ransom — is documented in https://tools.ietf.org/html/rfc7469#section-4.5. It was alsowas discussed (including the use of the term “pinning suicide”) in the IETF WebSec forum (see e.g. https://www.ietf.org/mail-archive/web/websec/current/msg02298.html and generally https://www.ietf.org/mailman/listinfo/websec). Basically, an attacker could effectively ransom the service operator or its users with or without LE, and with or without LE's rapid issuance process. This problem isn't unique to LE, and as mentioned above, has been known and discussed before. Short of offline and intentionally-slow issuance ceremonies — which would reduce the overall prevalence of HTTPS on the web, would still be spoofable, and would thus be a net negative for web security — demonstration of administrative control is the best available way for the site operator to prove their desire for LE to issue a certificate for the domain. We’re always interested in solving challenges, so thanks for taking the time to recommend a solution. Your recommendation to “Leverage DNS as proof that the true owner of any given domain actually wants a LE certificate” is effectively what Certification Authority Authorization (CAA, https://tools.ietf.org/html/rfc6844) is, and LE already uses it. Certificate Transparency provides effective post hoc misissuance detection, and LE uses it as well. Also, Chrome intentionally enabled the 60-day max-max-age to mitigate hostile pinning, in accordance with advice in https://tools.ietf.org/html/rfc7469#section-2.3.3.
,
Jun 21 2016
Hey Bryant / Ryan, Just checking in here - it seems as though palmer@'s response addressed the concerns your raised in the OP. As it doesn't look like there's anything to fix here on the Chrome side, any objections to marking this as WontFix and opening up the bug? I wanted to double check before doing so just to make sure I'm not missing something here.
,
Jun 21 2016
Tim and Chris, Thanks for taking the time to reply (and to check in). There are some details in Chris' reply which we disagree with, so we'll address everything in a subsequent reply this week. After this, we'll be content with any conclusion settled on by the team. Thanks for the ping.
,
Jun 21 2016
That timing sounds great - look forward to hearing from you later this week and I'll make pencil in some time in advance with Chris and others on the team to discuss on Monday.
,
Jun 24 2016
,
Jun 24 2016
Tentatively assigning security impact tags based on the fact that this attack requires taking over a web server
,
Jun 24 2016
,
Jun 25 2016
All, Ryan and I had a bit to get done this week which robbed us of necessary time, but I'm intending to follow up during the day Saturday. Thank you for the tags in the meantime.
,
Jun 26 2016
Interesting. We consistently get HTTP 500 status codes when attempting to post our reply even after filtering for characters within a specific range, so we're attaching it here as a (UTF-8) text file. Cheers, -Bryant and Ryan
,
Jun 27 2016
Attachment in #23 below. +agable: Any ideas why Bryant had issues uploading into Monorail? Also, for context I'm assigning Andrew as the new owner, as I'm leaving the Chrome team this week for elsewhere in Google and won't be able to see this through :( Andrew and I sit next to each other so he's very much up to speed on this and will likely get back to you today or tomorrow after chatting with Chris. In case I don't chat beforehand - all the best with your talk! Tim === attached email in #c23 === """Chris, thanks for your insight. It's always much appreciated. Generally, we do agree that CAA would be an effective mitigation for those not interested in using LE. As far as we're aware and judging from the spec, the spec essentially describes itself as a whitelist within a blacklist whereby when implemented by a domain, the domain must be precluded from receiving a certificate from a CA unless the CA observes itself in the CAA Resource Record set (RRs). Without an active mitigation effort, it would take a concerted awareness effort to make this known to all concerned service operators, which is something we intend to do with the AppSec Glory talk regardless of the outcome of this conversation. Ultimately, if the conclusion by all parties involved in this discussion is that there's nothing to be done short of making people aware of the opt-in CAA standard, we'll move forward with making awareness of the standard a priority. --- That said, we disagree with several details above. Specifically, > "Considering that, I would posit that the root problem is not with Let's Encrypt (LE), but with whatever vulnerability enabled the attacker to compromise the service in the first place. An attacker who can gain administrative control of the service has unlimited ability to damage the service, its users, and the operator's reputation in whatever way the attacker pleases. If an attacker has this type of unfettered access, attempting to extract a ransom via HPKP seems unlikely due to the possibility of significantly more interesting or lucrative alternatives" This appears to assume that compromising a site gives an attacker an unlimited ability to pivot, which for larger targets would not necessarily be the case. Building on this, it also assumes that every component of a site sits in one zone of trust, something I have yet to see at any larger corporate environment. To the point: just because a web server in a DMZ is compromised doesn't guarantee that an attacker can pivot and do substantially more damage through other means, or else there would be no point in having a DMZ at all. What would in the past have been just a simple site defacement could instead now be readily monetized by an attacker. Therefore, although an initial compromise might taken place through a different vulnerability, it is this vulnerability which allows an attacker to immediately cash out such a small scale intrusion. > "Basically, an attacker could effectively ransom the service operator or its users with or without LE, and with or without LE's rapid issuance process. This problem isn't unique to LE, and as mentioned above, has been known and discussed before." We disagree with the usage of the word "effectively" in this context. This problem appears in fact to be unique to LE simply because the issuance ceremony (automated via a bot on the web server) and rate limits are what allow an attacker to automate the attack and "lock in" the gains, meaning the users held for ransom. We haven't actually seen ransom attack patterns discussed in any of the aforementioned threads and references, only the concept of hostile pinning in a general sense, which we referenced in the original post (ctrl+f "hostile pinning"). We _did_ see discussion of ransom attack patterns arise spontaneously in other threads (ctrl+f "Hacker News"), but the crux of this report is that automated issuance, minimal authentication requirements, and rapid rotation of keys allow for a successful and effective attack as compared to without these capabilities. Without rapid key rotation specifically, defenders who regain access to the compromised machine can simply recover the keypair used in the attack, rendering such an attack entirely ineffective. > "Short of offline and intentionally-slow issuance ceremonies — which would reduce the overall prevalence of HTTPS on the web, would still be spoofable, and would thus be a net negative for web security — demonstration of administrative control is the best available way for the site operator to prove their desire for LE to issue a certificate for the domain." We don't actually believe that offline and intentionally slow issuance ceremonies would be an effective mitigation in light of the mission to spread TLS. However, we do believe that the free service LE provides obligates all parties -- LE as well as browsers which trust LE -- to investigate extra precautions. Speaking specifically to the use of CAA, our preference would be for LE to either require the use of CAA as a compromise condition for handing out free certificates at all _or_ for LE to require CAA as a condition for enabling higher rate limits. We believe the latter will be far less detrimental to LE's mission and can potentially even be beneficial by limiting abuse of the LE service. However, we've been informed by LE of the following: "CAA is intentionally a blacklist-based solution. To treat it as a whitelist would both violate the spec and create unnecessarily high barriers to enabling TLS." We've pored over the spec a number of times, especially section four (https://tools.ietf.org/html/rfc6844#section-4). We did not observe any defined behavior for CAs to follow in the event that a CAA RRs could not be located, which leads us to our understanding that CAs are empowered to explicitly require a CAA RRs as a condition of service without being in violation of the spec. --- To conclude: We believe that the level of system compromise required to enable RansomPKP is not a level of compromise which would guarantee the success of other attacks. For instance, all it might take to implement RansomPKP might be the compromise of a relevant web server within a DMZ, an otherwise limited network compromise which until now might not have been easily monetized. It's for this reason that we expect _some level of mitigation_ to take place, though as mentioned in the beginning, we can move forward with disclosing RansomPKP and releasing the PoC as part of a coordinated awareness effort for the use of CAA in the event that all concerned parties unfortunately decide against system-level mitigation. Our stance in favor of mitigation over merely an awareness campaign stems from the same position which led the Chromium team to cap max-max-age for HPKP to 60 days; service owners cannot necessarily be trusted to act in their own best interests hence the need for some form of programmatic enforcement, which gets to our closing point: Can the team confirm if our reading of the CAA specification is correct? We specifically did not observe any requirements in the spec for how to handle the condition where the RRs is empty. Because of this, an effective mitigation for this attack would seem to be for LE to require a CAA RRs identifying LE to be present as a condition of either issuing a certificate (more onerous to the adoption of TLS) or issuing a certificate beyond a certain cadence (far less burdensome yet still effective). We believe requiring CAA for certificates beyond two per month will substantially mitigate risk posed by this attack while still empowering LE to continue the mission of spreading TLS adoption, and though we strongly believe the Chromium team is in a unique position to suggest a change such as this in order to protect against such attacks in the future, we can understand and will move forward with only an awareness campaign should all product teams involved in this thread opt for WontFix. Cheers, -Bryant and Ryan"""
,
Jun 27 2016
(Aside, regarding the failure to post the update in Comment 23:) The attached text file contained unicode bytes in the following characters: lowercase 'x', capital 'F', and numeral '0'. I have no idea those characters were non-ascii. We plan to fully support utf8 (including emoji) in the near future; see issue monorail:705 for further details. If you wish to continue discussion about non-Basic Multilingual Plane characters in Monorail, feel free to contact me out-of-band, or in the issue referenced above. And now back to your regularly-scheduled programming.
,
Jun 27 2016
[offtopic] So first I drafted the reply in gdocs, then I copied it into notepad (a quick and easy way to sanitize things of specialness) and then into the comment box where it conveniently failed to post. No special ''s, ''es, or ''s were used. I know that it passed my extremely sloppy regex of [^a-zA-Z0-9\- /.?,"'+*_#:;>()\r\n] in notepad++ when I started to troubleshoot. The * character in the regex above was an em dash that had been used elsewhere in this thread, which makes me wonder if this is a regression in monorail that happened between when this thread opened and now. I had to pass the same 00ff-ffff regex on this text before I could submit _this_ comment, and that's the only character it caught. Original body for this comment.[/offtopic]
,
Jun 27 2016
Hi Bryant and Ryan, As you anticipated I'm going to mark this WontFix, given I don't believe there's a change to be made in Chrome. But we're certainly open to revisiting if there's a solution that improves current best practice. CAA records are indeed a promising development, and getting them more attention would be great, but this probably isn't the best forum for that discussion. I might suggest the Mozilla security policy list (https://lists.mozilla.org/listinfo/dev-security-policy) and keeping an eye on the CA/B Forum public list (https://cabforum.org/pipermail/public/). The latter requires membership to post, but I'd be happy to forward on any contributions if you'd like. Thanks again for taking the time to write a detailed report, and best of luck for your presentation!
,
Jun 27 2016
Fair. Is there an opinion by the Chrome team as to whether the LE team should investigate programmatic mitigation? There might not be anything in the opinion of the Chrome team that Chrome should perform to mitigate this, but we still believe that "a solution that improves current best practice" would be for free CAs--LE included--to require a CAA RRs when issuing certs beyond a certain rate limit per the last paragraph of our most recent response. My assumption is that our reading of the CAA spec is correct given that the team has not disputed it. If so, and if the Chrome team believes this is a step that LE should take, then I'd be glad to reopen the thread with the LE team (though they're already copied on every correspondence here). If not, then this topic is settled and we'll move forward with the presentation from there.
,
Jun 27 2016
[offtopic] I've created https://bugs.chromium.org/p/monorail/issues/detail?id=1511 for discussion of the unicode characters and Monorail. Please continue all other conversation over there. If you do not have permission to view that issue and wish to be granted access, please email me directly. [/offtopic]
,
Jun 27 2016
Speaking as one of the Chrome Team's representatives to the CA/Browser Forum, the suggestions with respect to CAA are ones that harm, rather than help, the ecosystem. Requiring free CAs to perform a CAA check would be explicitly harmful to the ecosystem, for reasons both obvious and non-obvious, but as I am not a lawyer, I cannot comment on nor speculate on. As Chris mentioned, the concerns regarding HPKP-centric ransomware were explicitly discussed during the standardization of HPKP. Free CAs do not meaningfully change that threat calculus, nor do CAs which allow unlimited issuance - such as CAs omitted from your list, such as StartCom or WoSign. The reading of the CAA spec - indicating that CAs could require CAA - is certainly true, but we're explicitly opposed and will not support a mandate that required CAA records be affirmatively present before issuing a certificate. This is not a step I can support recommending LE take, and believe it would be actively harmful to the ecosystem.
,
Jun 27 2016
Perfect response. Works for us. Will look forward to the discussion which will hopefully take place once we're done. If anyone from the team is attending either conference, we look forward to meeting in person!
,
Oct 4 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by bry...@zadegan.net
, Jun 16 2016