Re: Organization info in certs not being properly recognized byFirefox
On 10/31/2014 1:04 PM, Anne van Kesteren wrote: On Fri, Oct 31, 2014 at 11:22 AM, Moudrick M. Dadashov m...@ssc.lt wrote: The document below proposes a generic syntax for unique identification of natural/legal Subjects (see Section 5): http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN_319412-1v006-cert-profiles-common-structures_COMPLETE-draft.pdf Even if that works out, you're at best duplicating a system that is already in place with domain names. Sorry, no, actually the proposed syntax is completely independent of domain names. And it does not necessarily lead to simpler UI. It does lead to [at least] unified presentation of (legal/natural) Subject information and consequently to its consistent interpretation (UI). E.g. Apple now simply shows the Organization in the address bar, but with that mozilla.org and bugzilla.mozilla.org appear identical, while they actually have different security characteristics as far as the end user is concerned. Right, this is happening because security characteristics are dynamic while Subject information is static, so let's keep these things separate. Security characteristics are application specific and its the application to define how reliable Subject information is. The ETSI proposal above is about the syntax for unique Subject identification where we get both: the unique Subject ID and the ID of a registry that maintains those identities. Perhaps that would argue for showing both the Organization and the domain name as most other browsers appear to be doing, but that makes the UI is more complicated to grasp compared to DV or lacking TLS altogether. yes, this is something out of scope of the proposed syntax and needs some sort of standardization. Thanks, M.D. smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Re: Organization info in certs not being properly recognized byFirefox
On Wed, Oct 29, 2014 at 10:02 PM, Dean Coclin dean.j.coc...@verizon.net wrote: But many people do in fact look at the security indicators. If that statement were true, why do fraudsters bother to get SSL certs (mostly DV) for their phishing websites? Given that Organization is not a globally unique identifier, it seems they could with some more effort also spoof that field. (Which is why EV seems to actually make things more difficult for users as they have to carefully check the domain, the Organization field, and ensure that neither has changed, each time they visit.) -- https://annevankesteren.nl/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Organization info in certs not being properly recognized byFirefox
On 10/31/2014 11:20 AM, Anne van Kesteren wrote: On Wed, Oct 29, 2014 at 10:02 PM, Dean Coclin dean.j.coc...@verizon.net wrote: But many people do in fact look at the security indicators. If that statement were true, why do fraudsters bother to get SSL certs (mostly DV) for their phishing websites? Given that Organization is not a globally unique identifier, it seems they could with some more effort also spoof that field. (Which is why EV seems to actually make things more difficult for users as they have to carefully check the domain, the Organization field, and ensure that neither has changed, each time they visit.) The document below proposes a generic syntax for unique identification of natural/legal Subjects (see Section 5): http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN_319412-1v006-cert-profiles-common-structures_COMPLETE-draft.pdf Thanks, M.D. smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Organization info in certs not being properly recognized byFirefox
On Fri, Oct 31, 2014 at 11:22 AM, Moudrick M. Dadashov m...@ssc.lt wrote: The document below proposes a generic syntax for unique identification of natural/legal Subjects (see Section 5): http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN_319412-1v006-cert-profiles-common-structures_COMPLETE-draft.pdf Even if that works out, you're at best duplicating a system that is already in place with domain names. And it does not necessarily lead to simpler UI. E.g. Apple now simply shows the Organization in the address bar, but with that mozilla.org and bugzilla.mozilla.org appear identical, while they actually have different security characteristics as far as the end user is concerned. Perhaps that would argue for showing both the Organization and the domain name as most other browsers appear to be doing, but that makes the UI is more complicated to grasp compared to DV or lacking TLS altogether. -- https://annevankesteren.nl/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Re: Organization info in certs not being properly recognized byFirefox
I'd like to focus on this statement: "Users are, quite reasonably, focused on the viewport. After all, that's where the content is and where the task is. Many people simply never see the Location Bar or its security indicators."But many people do in fact look at the security indicators. If that statement were true, why do fraudsters bother to get SSL certs (mostly DV) for their phishing websites? It's because they know that people are trained to look for the lock and https. Granted not all the people know this but a percentage of the population does and it dictates the behavior of cybercriminals. DeanOn 10/28/14, fhw...@gmail.com wrote:It's debatable if those are actually facts but perhaps some perspective will help the conversation. I'll use this case as a launching point:* Users are, quite reasonably, focused on the viewport. After all, that's where the content is and where the task is. Many people simply never see the Location Bar or its security indicators.That is certainly a true statement and I would take it a step further to say the user should not be expected to check the address bar under normal circumstances. Or, to put it differently, any security feature which requires the user to pay close attention to the address bar should be considered ineffectual.That said, there is a use-case worth considering here: when the page being viewed doesn't look right. Examples include when I expected site A but end up at B, or when I go to login at C but instead have what looks like a phishing page. In such cases, seeing the organization info and so forth can be useful.Even if the best the browser can do is say "this site is owned by Google, although I really can't confirm it" there is utility in that. It just might give me a fighting chance at being secure--which is not to say the alternative is no chance but that my ability to make secure decisions are diminished without it. Original Message From: Chris PalmerSent: Monday, October 27, 2014 1:48 PMOn Mon, Oct 27, 2014 at 10:58 AM, John Nagle na...@sitetruth.com wrote: It's appropriate for browsers to show that new information with users. In the browser, there are two issues: 1) detecting OV certs, which requires a list of per-CA OIDs, and 2) displaying something in the GUI.If users perceive the new information — and that's a big if — what doyou expect that they will do with it?While formulating your response, please keep these facts in mind:* Users understand their task well enough to complete it, but are alsodistracted (including by security indicators and their numerous falsepositives), and busy. 0 people in the world understand 100% of the insand outs of X.509 and TLS; normal people have no chance and should nothave to. X.509-style PKI is an engineering failure in part because ofits absurd complexity.* Users are, quite reasonably, focused on the viewport. After all,that's where the content is and where the task is. Many people simplynever see the Location Bar or its security indicators.* The only security boundary on the web is the origin (the tuplescheme, host, port).* URLs are incredibly hard to parse, both for engineers (search theweb for hundreds of attempts to parse URLs with regular expressions!)and for normal people.* The only part of the origin that users understand is the hostname;it's better if the hostname is just effective TLD + 1 label below(e.g. example + co.sg, or example + com). Long hostnames look phishy.* User who look away from the viewport have a chance to understand 1bit of security status information: "Secure" or "Not secure".Currently, the guaranteed-not-safe schemes like http, ws, and ftp arethe only ones guaranteed to never incur any warning or bad indicator,leading people to reasonably conclude that they are safe. Fixing thatis the/a #1 priority for me; it ranks far higher thanever-more-fine-grained noise about organization names, hostnames,OV/DV/EV, and so on.* You can try to build a square by cramming a bunch of differentZooko's Triangles together, but it's probably going to be a majorbummer. After all, that's the status quo; why would more triangleshelp?* We have to design products that work for most people in the worldmost of the time, and which are not egregiously unsafe or egregiouslyhard to understand. It's good to satisfy small populations of powerusers if we can, but not at the expense of normal every day use.* There are some threat models for which no defense can be computed.For example, attempts to get to the "true" business entity, and toensure that they are not a proxy for some service behind, start tolook a lot like remote attestation. RA is not really possible even onclosed networks; on the internet it's really not happening.___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org
Re: Re: Organization info in certs not being properly recognized byFirefox
On Wed, Oct 29, 2014 at 2:02 PM, Dean Coclin dean.j.coc...@verizon.net wrote: But many people do in fact look at the security indicators. If that statement were true, why do fraudsters bother to get SSL certs (mostly DV) for their phishing websites? It's because they know that people are trained to look for the lock and https. Granted not all the people know this but a percentage of the population does and it dictates the behavior of cybercriminals. Some people do look at the security indicators some of the time. Since it's easy and affordable to get a certificate — as it should be! Thank you! And help me convince all the web developers out there who believe otherwise :) — phishers and fraudsters might as well pay the small price if they can soothe the concerns of some potential victims some of the time. Related: https://www.ccsl.carleton.ca/people/theses/Sobey_Master_Thesis_08.pdf 5.4 Time Spent Gazing at Browser Chrome One of the more interesting findings in the eye tracking data was how long users spent gazing at the content of the web pages as opposed to gazing at the browser chrome. For each participant, we compared the amount of time the participant’s gaze data contained co-ordinates within the browser chrome during the study tasks with the amount of time the participant’s gaze data contained co-ordinates in the page content. On average, the 11 participants who were classified as gazers spent about 9.5% of time gazing at any part of the browser chrome. The remaining 17 participants who did not gaze at indicators spent only 4.3% of their time focusing on browser chrome as opposed to content (some spent as little as 1%). Tangentially related: http://eprints.qut.edu.au/55714/1/Main-ACM.pdf ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Organization info in certs not being properly recognized byFirefox
It's debatable if those are actually facts but perhaps some perspective will help the conversation. I'll use this case as a launching point:* Users are, quite reasonably, focused on the viewport. After all, that's where the content is and where the task is. Many people simply never see the Location Bar or its security indicators.That is certainly a true statement and I would take it a step further to say the user should not be expected to check the address bar under normal circumstances. Or, to put it differently, any security feature which requires the user to pay close attention to the address bar should be considered ineffectual.That said, there is a use-case worth considering here: when the page being viewed doesn't look right. Examples include when I expected site A but end up at B, or when I go to login at C but instead have what looks like a phishing page. In such cases, seeing the organization info and so forth can be useful.Even if the best the browser can do is say "this site is owned by Google, although I really can't confirm it" there is utility in that. It just might give me a fighting chance at being secure--which is not to say the alternative is no chance but that my ability to make secure decisions are diminished without it. Original Message From: Chris PalmerSent: Monday, October 27, 2014 1:48 PMOn Mon, Oct 27, 2014 at 10:58 AM, John Nagle na...@sitetruth.com wrote: It's appropriate for browsers to show that new information with users. In the browser, there are two issues: 1) detecting OV certs, which requires a list of per-CA OIDs, and 2) displaying something in the GUI.If users perceive the new information — and that's a big if — what doyou expect that they will do with it?While formulating your response, please keep these facts in mind:* Users understand their task well enough to complete it, but are alsodistracted (including by security indicators and their numerous falsepositives), and busy. 0 people in the world understand 100% of the insand outs of X.509 and TLS; normal people have no chance and should nothave to. X.509-style PKI is an engineering failure in part because ofits absurd complexity.* Users are, quite reasonably, focused on the viewport. After all,that's where the content is and where the task is. Many people simplynever see the Location Bar or its security indicators.* The only security boundary on the web is the origin (the tuplescheme, host, port).* URLs are incredibly hard to parse, both for engineers (search theweb for hundreds of attempts to parse URLs with regular expressions!)and for normal people.* The only part of the origin that users understand is the hostname;it's better if the hostname is just effective TLD + 1 label below(e.g. example + co.sg, or example + com). Long hostnames look phishy.* User who look away from the viewport have a chance to understand 1bit of security status information: "Secure" or "Not secure".Currently, the guaranteed-not-safe schemes like http, ws, and ftp arethe only ones guaranteed to never incur any warning or bad indicator,leading people to reasonably conclude that they are safe. Fixing thatis the/a #1 priority for me; it ranks far higher thanever-more-fine-grained noise about organization names, hostnames,OV/DV/EV, and so on.* You can try to build a square by cramming a bunch of differentZooko's Triangles together, but it's probably going to be a majorbummer. After all, that's the status quo; why would more triangleshelp?* We have to design products that work for most people in the worldmost of the time, and which are not egregiously unsafe or egregiouslyhard to understand. It's good to satisfy small populations of powerusers if we can, but not at the expense of normal every day use.* There are some threat models for which no defense can be computed.For example, attempts to get to the "true" business entity, and toensure that they are not a proxy for some service behind, start tolook a lot like remote attestation. RA is not really possible even onclosed networks; on the internet it's really not happening. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Organization info in certs not being properly recognized byFirefox
On 27/10/14 08:16, Ryan Sleevi wrote: snip If you're trusting certificates to assert information about either the identity of the entity behind the key or that the CA has done due diligence, well, you're using certificates for something they're neither intended for nor well suited for, so you'll have a bad time. Ryan, you are of course free to reach your own conclusions about what certs are / aren't well suited for. However, I'm utterly baffled by your claim that certificates aren't intended to assert information about...the identity of the entity behind the key. That claim is true for DV, but it's clearly false for EV and OV. As for due diligence, BRs Section 11.2 clearly says that CAs are required to verify organization info in accordance with Section 11.2 and as documented in their CP/CPS. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Organization info in certs not being properly recognized byFirefox
On 27/10/14 08:16, Ryan Sleevi wrote: snip If you're trusting certificates to assert information about either the identity of the entity behind the key or that the CA has done due diligence, well, you're using certificates for something they're neither intended for nor well suited for, so you'll have a bad time. In May 2012, when this was last discussed, that was a reasonable position. There have been some changes in standard CA practice since then. Originally, the CA/Browser Forum was only concerned with EV certs. Back in May 2012 the CA/Browser Forum was discussing the Baseline Guidelines, but they were not in effect yet. So, in May 2012, it was reasonable to say that extracting reliable Organization and Location information from non-EV certs was an unreliable process. In July 2012, the CA/Browser Forum Baseline Guidelines for all certs, not just EV, took effect. Once those came out, CAs started making a clear distinction between DV, OV, and EV certs. Previously, DV vs OV had only been an informal distinction. Two years later, many issued certs (soon I'll know how many) bear OIDs which clearly identify them as OV certs, with the CA standing behind the Organization and Location information. It's appropriate for browsers to show that new information with users. In the browser, there are two issues: 1) detecting OV certs, which requires a list of per-CA OIDs, and 2) displaying something in the GUI. John Nagle SiteTruth On 10/27/2014 01:58 AM, Rob Stradling wrote: Ryan, you are of course free to reach your own conclusions about what certs are / aren't well suited for. However, I'm utterly baffled by your claim that certificates aren't intended to assert information about...the identity of the entity behind the key. That claim is true for DV, but it's clearly false for EV and OV. As for due diligence, BRs Section 11.2 clearly says that CAs are required to verify organization info in accordance with Section 11.2 and as documented in their CP/CPS. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Organization info in certs not being properly recognized byFirefox
On Mon, Oct 27, 2014 at 10:58 AM, John Nagle na...@sitetruth.com wrote: On 27/10/14 08:16, Ryan Sleevi wrote: snip If you're trusting certificates to assert information about either the identity of the entity behind the key or that the CA has done due diligence, well, you're using certificates for something they're neither intended for nor well suited for, so you'll have a bad time. In May 2012, when this was last discussed, that was a reasonable position. There have been some changes in standard CA practice since then. Yes, however there are plenty of certs still in use that are unexpired which don't follow these standard practices. Specifically, from the CT logs, 139935 certificates that are unexpired meet the following criteria: - Do not have a State/Province or Locality Name in the Subject - Have the same string for Organization and Common Name in the subject The string used for the Organization Name appears to be a fully qualified domain name in the certificates that I checked. I trust that this practice is not happening in new certificates, but thousands of existing certificates clearly have Organization Name attributes that are not usable. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Organization info in certs not being properly recognized byFirefox
On Mon, Oct 27, 2014 at 10:58 AM, John Nagle na...@sitetruth.com wrote: It's appropriate for browsers to show that new information with users. In the browser, there are two issues: 1) detecting OV certs, which requires a list of per-CA OIDs, and 2) displaying something in the GUI. If users perceive the new information — and that's a big if — what do you expect that they will do with it? While formulating your response, please keep these facts in mind: * Users understand their task well enough to complete it, but are also distracted (including by security indicators and their numerous false positives), and busy. 0 people in the world understand 100% of the ins and outs of X.509 and TLS; normal people have no chance and should not have to. X.509-style PKI is an engineering failure in part because of its absurd complexity. * Users are, quite reasonably, focused on the viewport. After all, that's where the content is and where the task is. Many people simply never see the Location Bar or its security indicators. * The only security boundary on the web is the origin (the tuple scheme, host, port). * URLs are incredibly hard to parse, both for engineers (search the web for hundreds of attempts to parse URLs with regular expressions!) and for normal people. * The only part of the origin that users understand is the hostname; it's better if the hostname is just effective TLD + 1 label below (e.g. example + co.sg, or example + com). Long hostnames look phishy. * User who look away from the viewport have a chance to understand 1 bit of security status information: Secure or Not secure. Currently, the guaranteed-not-safe schemes like http, ws, and ftp are the only ones guaranteed to never incur any warning or bad indicator, leading people to reasonably conclude that they are safe. Fixing that is the/a #1 priority for me; it ranks far higher than ever-more-fine-grained noise about organization names, hostnames, OV/DV/EV, and so on. * You can try to build a square by cramming a bunch of different Zooko's Triangles together, but it's probably going to be a major bummer. After all, that's the status quo; why would more triangles help? * We have to design products that work for most people in the world most of the time, and which are not egregiously unsafe or egregiously hard to understand. It's good to satisfy small populations of power users if we can, but not at the expense of normal every day use. * There are some threat models for which no defense can be computed. For example, attempts to get to the true business entity, and to ensure that they are not a proxy for some service behind, start to look a lot like remote attestation. RA is not really possible even on closed networks; on the internet it's really not happening. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
