Mikko Rantalainen wrote:
> I'd much rather see world where CA signs whatever they want and trust is
> handled separately, hopefully using some kind of web-of-trust algorithm.
Cert pinning?
Ciao, Michael.
___
dev-security mailing list
dev-security@lis
Mikko Rantalainen wrote:
> On Friday, 16 August 2013 12:01:51 UTC+3, Gervase Markham wrote:
>> 2. Limited cert lifetimes mean that if an algorithm starts to look dodgy
>> (e.g. as MD5 did) we can move the industry to new algorithms without
>> having to worry about 20-year end-entity certs. This is
> Also, it's worth bearing in mind that the number of bits is a
> distractor. All the weakness comes from elsewhere, so fiddling around
> with the bits is just so much numerology that amuses NIST and numerate
> managers and others. It does little for overall security.
Well it is not a distrac
On 22/08/13 07:09, Mikko Rantalainen wrote:
> Perhaps I'm not an average user but I would like to be informed about
> changed key in all those cases.
You are definitely not the average user.
>>> 2 year certs if time limit increases security? Why not issue a
>>> new signature every day and be done
On 22/08/13 09:09 AM, Mikko Rantalainen wrote:
On Friday, 16 August 2013 12:01:51 UTC+3, Gervase Markham wrote:
On 15/08/13 11:22, Mikko Rantalainen wrote:
No. The site's public key does not need to be changed to request a
new certificate.
Technically, no. But there are other occasions on w
On Thursday, 22 August 2013 09:09:06 UTC+3, Mikko Rantalainen wrote:
> If we really believed that shorter lifetime is required for the keys,
> we would be replacing those CA keys already.
I'd like to add that in my opinion, the lifetime should be decided by the user
agent (default) or by the use
On Friday, 16 August 2013 12:01:51 UTC+3, Gervase Markham wrote:
> On 15/08/13 11:22, Mikko Rantalainen wrote:
>
> > No. The site's public key does not need to be changed to request a
> > new certificate.
>
> Technically, no. But there are other occasions on which it does - key
> length upgrade
A new version of Firefox/Chrome is deployed to (nearly) all Firefox/Chrome
users within a week or two. AFAIK, There is no auto-upgrade from IE9 to
IE10 (only one I know of is IE10 to IE11).
I believe that as a result of above, compat hit is a bigger concern for
Firefox/Chrome than it is for IE. We
On 8/19/13 11:51 AM, Devdatta Akhawe wrote:
I also think the comparison to IE is not apt---in the absence of
auto-upgrade, the compat hit IE takes is much lower. A more apt comparison
is Chrome, which didn't block mixed content iframes.
cheers
Dev
Hi Dev,
What do you mean about the comparison
>
>
> [0] I don't know for sure, but it is my suspicion that bayesian statistics
> explains this more clearly. If there is anyone in the house that actually
> knows it, please speak...
>
>
https://sparrow.ece.cmu.edu/group/731-s09/readings/Axelsson.pdf provides a
fantastic overview of the problem
> Sure, but warnings are useless. Some people -- us -- might follow them.
> Most have been trained for so long to click through them that they no
> longer read them. Click-thru syndrome is a sad result of unreliable
> systems: if the False Negatives (wrong warnings) are too frequent, and
>
On 16/08/13 20:09 PM, Kevin Chadwick wrote:
and the thread Subject is spot on.
How about
War on mixed content - why not?
Warnings have been popping up for as long as I can remember so the
likely hood is that if they haven't fixed the site, they have chosen not
to. I could understa
> 2. Limited cert lifetimes mean that if an algorithm starts to look dodgy
> (e.g. as MD5 did) we can move the industry to new algorithms without
> having to worry about 20-year end-entity certs. This is why we have been
> pushing in the CAB Forum for shorter max cert lifetimes. It's the CAs
> who
> and the thread Subject is spot on.
How about
War on mixed content - why not?
Warnings have been popping up for as long as I can remember so the
likely hood is that if they haven't fixed the site, they have chosen not
to. I could understand an argument that the warning could have chan
On 15/08/13 11:22, Mikko Rantalainen wrote:
> No. The site's public key does not need to be changed to request a
> new certificate.
Technically, no. But there are other occasions on which it does - key
length upgrade, cert private key loss or compromise (or possible
compromise). In the current sy
To repeat, the positions are entrenched, and it isn't worth repeating
the debate. The main point to understand is that:
*the browsers have to block mixed content*
and the thread Subject is spot on.
(fwiw, some easy rebuttal below, and why.)
iang
On 15/08/13 12:27 PM, Gervase Markham wr
On 8/15/2013 11:21 AM, ianG wrote:
> On 15/08/13 13:22 PM, Mikko Rantalainen wrote:
>> Why not issue a new signature every day and be done with
>> broken revocation lists?)
>
> You'll upset people if you start talking like that :)
Not really, it's a serious proposal for dealing with the revocatio
> > I'm trying to argue that current non-EV certification process is no good
> > and self-signed certificates can be used to provide equal security in
> > practice. Then we can discuss if browsers should display some kind of
> > "secure" indicators for HTTPS connections with non-EV certs/self-si
On 15/08/13 13:22 PM, Mikko Rantalainen wrote:
On Thursday, 15 August 2013 12:23:18 UTC+3, Gervase Markham wrote:
On 14/08/13 07:09, Mikko Rantalainen wrote:
I'd say that such a bookmark would be highly probably safe, if that
bookmark did include fingerprint for the site public key (*not CA k
> On Wednesday, 14 August 2013 12:21:15 UTC+3, Kevin Chadwick wrote:
> > > This is because the cheapest CAs do so bad work that the
> > > security is very close to self signed cert.
> >
> > Please show me evidence of startssl being less secure than some of the
> > big CAs that have had major inci
> > So now you trust a user writable reference over a non writable installed
> > CA crt (I hope soon to be replaced by website provided keys signed by
> > mozilla/Google)
>
> Are you trying to say that there is a meaningful class of attacks that can
> modify user's bookmark store and still not
> On Thursday, 15 August 2013 12:23:18 UTC+3, Gervase Markham wrote:
> > On 14/08/13 07:09, Mikko Rantalainen wrote:
> >
> > > I'd say that such a bookmark would be highly probably safe, if that
> > > bookmark did include fingerprint for the site public key (*not CA key
> > > fingerprint*) and th
On Thursday, 15 August 2013 12:23:18 UTC+3, Gervase Markham wrote:
> On 14/08/13 07:09, Mikko Rantalainen wrote:
>
> > I'd say that such a bookmark would be highly probably safe, if that
> > bookmark did include fingerprint for the site public key (*not CA key
> > fingerprint*) and the browser di
On Wednesday, 14 August 2013 12:03:22 UTC+3, Kevin Chadwick wrote:
> > Say you have an HTTPS bookmark to your bank. You visit it (your techie
> > friend told you "always use this bookmark for your bank, and you'll be
> > safe"),
>
> So now you trust a user writable reference over a non writable i
On Wednesday, 14 August 2013 12:21:15 UTC+3, Kevin Chadwick wrote:
> > This is because the cheapest CAs do so bad work that the
> > security is very close to self signed cert.
>
> Please show me evidence of startssl being less secure than some of the
> big CAs that have had major incidents. You o
On 13/08/13 18:11, ianG wrote:
> Badly. Riddled with bad, false and self-serving assumptions. here's
> just one:
>
>"Before we begin, we must understand that
>Security = Encryption * Authentication."
>
> Wrong. That happens to be the SSLv2 security offering, aka C.I.A. for
> co
On 14/08/13 07:09, Mikko Rantalainen wrote:
> I'd say that such a bookmark would be highly probably safe, if that
> bookmark did include fingerprint for the site public key (*not CA key
> fingerprint*) and the browser did verify the fingerprint before
> entering the site.
Except that the bookmark
> Say you have an HTTPS bookmark to your bank. You visit it (your techie
> friend told you "always use this bookmark for your bank, and you'll be
> safe"),
So now you trust a user writable reference over a non writable installed
CA crt (I hope soon to be replaced by website provided keys signed by
> This is because the cheapest CAs do so bad work that the security is very
> close to self signed cert.
Please show me evidence of startssl being less secure than some of the
big CAs that have had major incidents. You only need to send them a csr
too.
Then realise that we should be concentrati
On Tuesday, 13 August 2013 14:59:15 UTC+3, Gervase Markham wrote:
> On 13/08/13 08:44, Mikko Rantalainen wrote:
>
> > I cannot speak for Ian, but I'd guess "neutral" mode means something
> > along the lines "use encrypted connection but do not show any
> > additional 'secure' UI decorations". Tha
On 13/08/13 14:59 PM, Gervase Markham wrote:
On 13/08/13 08:44, Mikko Rantalainen wrote:
I cannot speak for Ian, but I'd guess "neutral" mode means something
along the lines "use encrypted connection but do not show any
additional 'secure' UI decorations". That would be suitable for cases
where
On 13/08/13 08:44, Mikko Rantalainen wrote:
> I cannot speak for Ian, but I'd guess "neutral" mode means something
> along the lines "use encrypted connection but do not show any
> additional 'secure' UI decorations". That would be suitable for cases
> where site wants to protect the user input and
> Chrome's implementation is a little less secure since
> it does not block mixed iframes and mixed xhr. However, they are working
> on improving their Mixed Content Blocker.
I wouldn't be surprised if this is because it would break some
of Google's sites. You can't even navigate Google plus wi
On 13/08/13 10:44 AM, Mikko Rantalainen wrote:
On Tuesday, 13 August 2013 00:59:24 UTC+3, Tanvi Vyas wrote:
I filed a bug for this and welcome feedback and
suggestions: https://bugzilla.mozilla.org/show_bug.cgi?id=903211.
Thanks for the pointers. I added a comment to that bug.
On a side not
On Tuesday, 13 August 2013 00:59:24 UTC+3, Tanvi Vyas wrote:
> I filed a bug for this and welcome feedback and
> suggestions: https://bugzilla.mozilla.org/show_bug.cgi?id=903211.
Thanks for the pointers. I added a comment to that bug.
> On a side note, Ian mentioned a "neutral" mode for SSL, an
Hi Mikko,
Thanks for your comments! Chrome, IE, and Firefox all have a Mixed
Content Blocker. Chrome's implementation is a little less secure since
it does not block mixed iframes and mixed xhr. However, they are working
on improving their Mixed Content Blocker. Chrome 30 (currently Chrome
On 8/12/13 12:59 AM, mikko.rantalai...@gmail.com wrote:
Cons:
(2) Breaks existing sites that used to work in Firefox 22 and Chrome. (Granted,
most of such sites were already broken in MSIE.)
Chrome also already implements mixed content blocking.
Justin
_
On Monday, 12 August 2013 11:27:59 UTC+3, ianG wrote:
> The only 'solution' is really to put everything into the secure side.
Unfortunately, I cannot control everything. I'm authoring a kind of CMS system
for educational use and I need to support user authored content. The whole
system uses onl
It's complicated. Mixed content has always broken the security model
espoused by SSL. It wasn't actually mixed content that originally broke
it, rather it was the speed/cpu requirements that slowed down the
browsing, so sites deployed the SSL only for their secure credit card
collection. (I'
I had totally missed that Firefox 23 turned on Mixed Content blocking. What is
the rationale for that?
I'm aware that MSIE blocked mixed content but I always considered that a bug.
In short, I see mixed content blocking pros and cons as follows:
Pros:
(1) Avoid MitM attack for HTTPS sites that
40 matches
Mail list logo
