Re: [websec] Authentic inter-domain relationships. Is this a security problem? Appropriate for websec?

On 12/01/15 19:18, Chris Hartmann wrote: > 2) a.com forms a business relationship with b.com to perform a > business function on its behalf (payment processor, blog, whatever). > The landing page is b.com/a Would it not be reasonable to say that, when this sort of relationship is set up, best prac

Re: [websec] I-D Action: draft-nir-websec-extended-origin-00.txt

On 23/02/12 00:26, Manger, James H wrote: Wouldn’t it be better for SSL VPNs to use lots of sub-domains? For instance, to map internal sites to: https://a.sslvpn.example.com/webmail https://b.sslvpn.example.com/wiki/index.html https://c.sslvpn.example.com/stuff This would be much better. It

Re: [websec] Is sniffing a heuristic? (was Re: more on sniffing)

On 08/01/12 23:08, Bjoern Hoehrmann wrote: > In computer science heuristics are problem-solving techniques that pro- > vide good but not neccesarily correct solutions; they are employed as a > trade-off between correctness and other desirable properties. (Slightly off-topic) I rather like this de

Re: [websec] Test of XHR in HTML mail

On 12/12/11 20:07, Richard L. Barnes wrote: > In fact, it doesn't look like they're even processing the onload > handler for the element (except for Gmail). That black line > you see is a collapsed , and it should be hidden on load. Maybe > MUAs just aren't supporting Javascript? --Richard It's

Re: [websec] Digest URI scheme

On 27/09/11 18:10, Phillip Hallam-Baker wrote: > On the digest front the objective would be to make it possible to use > the URI format with any digest at all in theory but strongly encourage > people to only use the digests IETF is confident in. Use of OIDs as > the identifier has the nice propert

Re: [websec] Pinning and beyond Was: Next rev of HSTS certificate pinning draft

On 21/09/11 14:18, Phillip Hallam-Baker wrote: > Promiscuous security: > The site deploys SSL as an option that browsers can choose to use. > Pages may include transcluded content from insecure sites. The cert may > just be a self signed cert, browsers should just silently upgrade the > transpo

Re: [websec] Certificate Pinning via HSTS (.txt version)

On 13/09/11 13:06, Marsh Ray wrote: > Or not, like the Dutch government, have the pull to convince Mozilla to > hesitate for a few days to revoke your pwned CA. That is rather unfair. You make it sound like they asked, and we complied. In truth, we relied on an assessment of the situation from Gov

Re: [websec] WG Last Call on draft-ietf-websec-origin-02 until Aug-15

Hi Adam, I've only just read this document; I didn't realise it contained a dis-recommendation for the use of the Public Suffix List. I couldn't see in the document any other way of allowing two non-identical but related origins to collaborate. Do you have a recommendation for this use case (a nu

Re: [websec] Public Suffix definition

On 25/07/11 13:59, Yngve N. Pettersen wrote: >> Do you have a script which converts from the currently-standard format >> at publicsuffix.org to the proposed new format? > > Not in a public location, at present, sorry. I think that would be helpful for people to evaluate your proposal. Gerv

Re: [websec] Public Suffix definition

On 25/07/11 11:17, Yngve N. Pettersen wrote: > This draft, which tries to define the term "Public Suffix", as used in > cookies and document.domain, and elsewhere, may be of interest to the > websec group. > > Hi Yngve, Do you have

Re: [websec] HSTS: Maintenance of hardcoded lists in clients

On 25/07/11 11:13, Yngve N. Pettersen wrote: > At least one client supporting HSTS (maybe more) is using a hardcoded > list of sites that are always HSTS enabled, as a method of countering > the bootstrap problem. Is "the bootstrap problem", the problem that on your very first visit to a site, you