On 15/12/2017 02:30, Ryan Sleevi wrote:
On Thu, Dec 14, 2017 at 5:01 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 14/12/2017 00:23, Peter Gutmann wrote:
Tim Shirley via dev-security-policy <
dev-security-policy@lists.mozilla.org> writes:
But rega
Has anyone started looking into CA issuances -- or even more importantly -- CA
domain validations performed successfully and yet without issuing a certificate
(say, wanting to cache the validation) for the brief periods in which much of
the internet saw alternative target destinations for a grea
On Thu, Dec 14, 2017 at 5:01 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 14/12/2017 00:23, Peter Gutmann wrote:
> > Tim Shirley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
> >
> >> But regardless of which (or neither) is
That attack was by hacking the target's domain registrar account. Others have
done that as well, including against a Brazilian bank.
The right attacker would not even need that - they could just hijack traffic
headed to the IP address of the real DNS server in question.
On Thu, Dec 14, 2017 at 3:31 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I have several questions for the community to ponder:
>
> 1. If a technologically detectable and authenticatable indicator that a
> site was "measurably more trustworthy than
On Thursday, December 14, 2017 at 5:50:40 PM UTC-6, Matthew Hardeman wrote:
> Route hijacking your way to what would appear as a proper domain validation
> is practical for even a modestly resourceful adversary. I suspect that the
> only reason more spectacular demonstration of certs issuing pu
On Wednesday, December 13, 2017 at 2:46:10 PM UTC-6, Gervase Markham wrote:
> My concern with this argument is that it's susceptible to the criticism
> that Adam Langley made of revocation checking:
> https://www.imperialviolet.org/2012/02/05/crlsets.html
>
> "So [EV identity is] like a seat-belt
On 14/12/2017 00:23, Peter Gutmann wrote:
Tim Shirley via dev-security-policy
writes:
But regardless of which (or neither) is true, the very fact that EV certs are
rarely (never?) used on phishing sites
There's no need:
https://info.phishlabs.com/blog/quarter-phishing-attacks-hosted-https-
On 13/12/2017 22:40, Matthew Hardeman wrote:
On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote:
Yes. This is the foundation and limit of Web Security.
https://en.wikipedia.org/wiki/Same-origin_policy
This is what is programatically enforced. Anything else either requires ne
On 13/12/2017 20:55, Gervase Markham wrote:
On 11/12/17 17:00, Ryan Sleevi wrote:
Fundamentally, I think this is misleading. It presumes that, upon
something bad happening, someone can link it back to that certificate
to link it back to that identity. If I was phished, and entered my
credentials
On 14/12/2017 17:51, Peter Bachman wrote:
@Jakob I was referring to the classical namespaces which have evolved since the
1980s. The NSF pilot project was based on a now obsolete version of X.500,
Quipu, that world rooted with participating county directories. While I
managed that part of the
All,
Recent events and a body of historical research have of late been causing
questions among a great many respected security researchers and browser UI
guys about the benefits of browser UI signal for EV certificates.
I'd like to start a discussion tangent to that ongoing dialogue.
Regardless o
@Ryan
“Since improving it as a technical means is an effective non-starter (e.g.
introducing a new origin for only EV certs), the only fallback is to the
cognitive means”
EV is a convenient signal. I like it. The problem is the infrastructure that
pits the Internet and it’s protocols with in
@Jakob I was referring to the classical namespaces which have evolved since the
1980s. The NSF pilot project was based on a now obsolete version of X.500,
Quipu, that world rooted with participating county directories. While I
managed that part of the capital D Directory it was in the context o
As much as I hate to thread-police, I do want to re-iterate that the
discussion about whether CAs should or should not issue certificates to
legitimate domain holders, and/or whether they should revoke such
certificates for domain holders, is itself an entirely separate issue, and
one has been disc
Niklas,
That's fine. Thanks for the heads up. Note that the format has a
possibility of changing some in 2018, but only in the way of adding fields,
not changing existing data.
Cheers,
J.C.
Crypto Engineering
On Thu, Dec 14, 2017 at 9:03 AM, niklas.bachmaier--- via
dev-security-policy wrote:
Of course, the main reason Comodo gets sucked into this swamp is the
price point. That isn't necessarily their fault.
As I've pointed out elsewhere, Comodo has some great ideas about fixing
revocation that would go a long way towards solving the "misbehave only
after issuance" problem that you
Within 24 hours? Once the download completes? It doesn’t seem significantly
harder than the other questions we grapple with. I’m sure there are plenty of
reasonable solutions.
If you want to deliver the private key first, before issuance, that’d be fine
too. It just means two downloads i
We are now ready to use the OneCRL in production. Approximately 2500 hosts
would be requesting one OneCRL copy per day. Please let me know if this is not
okay for you.
Thanks a lot
Niklas
___
dev-security-policy mailing list
dev-security-policy@lists.
On 14/12/17 00:25, Tim Hollebeek via dev-security-policy wrote:
If you look at where the HTTPS phishing certificates come from, they come
almost entirely from Let's Encrypt and Comodo.
This is perhaps the best argument in favor of distinguishing between CAs
that care about phishing and those tha
20 matches
Mail list logo
