s/24
8 - https://support.mozilla.org/en-US/questions/990082
9 -
https://productforums.google.com/forum/#!searchin/youtube/rc4/youtube/
VuVshylMDO0/EMuBNFmgQLwJ
--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
- Original Message -
> From: "Brian Smith"
> To: "mozilla's crypto code discussion list"
>
> Sent: Monday, June 30, 2014 12:23:41 AM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On Sun, Jun 29, 2014 at 11:18 A
- Original Message -
> From: "Kurt Roeckx"
> To: mozilla-dev-tech-cry...@lists.mozilla.org
> Sent: Monday, 30 June, 2014 10:56:13 AM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On 2014-06-30 02:35, Hubert Kario wrote:
> >&g
- Original Message -
> From: "Brian Smith"
> To: "mozilla's crypto code discussion list"
>
> Sent: Monday, 30 June, 2014 12:23:41 AM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On Sun, Jun 29, 2014 at 11:18 A
- Original Message -
> From: "Kurt Roeckx"
> To: mozilla-dev-tech-cry...@lists.mozilla.org
> Sent: Monday, 30 June, 2014 1:57:33 PM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On 2014-06-30 12:20, Hubert Kario wrote:
> >&
- Original Message -
> From: "Brian Smith"
> To: "mozilla's crypto code discussion list"
>
> Sent: Tuesday, 1 July, 2014 10:58:27 PM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On Sun, Jun 29, 2014 at 5:35 PM
-SHA256
RC4-SHA
DHE-RSA-AES128-SHA
AES128-SHA
will negotiate RC4 with Firefox. Such configuration has about 2% of
servers.
--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
- Original Message -
> From: "Brian Smith"
> To: "mozilla's crypto code discussion list"
>
> Sent: Thursday, 10 July, 2014 3:02:34 AM
> Subject: Re: Road to RC4-free web (the case for YouTube without RC4)
>
> On Wed, Jul 2, 2014 at 5:08 AM,
f-tls-downgrade-scsv-00 to NSS, Gecko, and Firefox.
What basis do you have to assume that server administrators will actually
upgrade their Apache/nginx/lighttpd/OpenSSL/etc. installations?
There are many installation that still haven't fixed their servers after
Heartbleed (0.5%) or the CCS vulne
hout RC4)
>
> On Thu, Jul 10, 2014 at 5:00 AM, Hubert Kario wrote:
> > - Original Message -
> >> From: "Brian Smith"
>
>
>
> >> However, it is likely that crypto libraries that make the two changes
> >> above
> >>
nvalid. (Error code: sec_error_ca_cert_invalid) from Linux
> But from Windows it work fine
This is not externally reachable.
Could you connect to it using
openssl s_client -showcerts -connect 9.183.191.164:443
and attach full output?
There were few changes that could have caused it.
--
Regards,
do the TLS downgrade dance.
1 -
https://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/
--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
be workable in real world, or we can try to make the systems secure in
real world for people that care (both users and server admins that
do apply updates regularly).
Yes, I'd like to live in a world where it's not necessary, but we don't.
--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
ed in OpenSSL to make it safe.
So, any comments to the proposed changes in opening mail?
--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
On Tuesday 21 October 2014 16:10:52 Julien Pierre wrote:
> Hubert,
>
> On 10/21/2014 05:06, Hubert Kario wrote:
> > Yes, it's external to the TLS, and yes, it's bad that browsers do use
> > the manual fallback. Yes, the servers should be regularly updated and
>
On Wednesday 22 October 2014 00:59:53 Brian Smith wrote:
> On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario wrote:
> > The number of sites that prefer RC4 while still supporting other ciphers
> > are
> > very high (18.6% in June[1], effectively 21.3% for Firefox[6]) and not
&
On Wednesday 22 October 2014 15:54:57 Julien Pierre wrote:
> Hubert,
>
> On 10/22/2014 05:27, Hubert Kario wrote:
> > Problem is that if something doesn't work in one browser and does in
> > another users blame the browser. Even if the browser that doesn't work
>
On Saturday 25 October 2014 14:26:59 Julien Vehent wrote:
> Thank you Hubert from starting this discussion. I think this can be the
> base for version 4 of the document.
>
> On 2014-10-20 08:10, Hubert Kario wrote:
> > The items that probably should be changed or added:
> &g
On Saturday 08 November 2014 10:29:06 Kosuke Kaizuka wrote:
> On Thu, 23 Oct 2014 01:35:08 +0900, Kosuke Kaizuka wrote:> On Wed, 22
>
> Oct 2014 00:59:53 -0700, Brian Smith wrote:
> >> On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario wrote:
> >>> The number of
ion detail in NSS, though it could in
theory be reused for X.509.
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
--
I found at least 439 servers which support
only 3DES and have valid certificates. If Firefox removes RC4, I'm sure that
this will make this number effectively only larger (80% of servers still
support RC4, 15% prefer RC4 over any and all ciphers).
--
Regards,
Hubert Kario
Quality Engineer,
On Monday 02 March 2015 13:51:24 Kurt Roeckx wrote:
> On 2015-03-02 13:32, Hubert Kario wrote:
> > Not true. In Alexa top 1 million I found at least 439 servers which
> > support
> > only 3DES and have valid certificates. If Firefox removes RC4, I'm sure
> >
n't be able to handle
certificate, so it doesn't send any and aborts connection without telling
client why (thus the incomprehensible error message).
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno,
t
happens with a given TLS implementation or server when the other side
doesn't meet its expectations, it should be fairly easy to extend
tlsfuzzer[1] with this feature (pull requests more than welcome, and I
actually do plan to work on this myself in November).
1 - https://github.com/tom
keys as 'ecKey'
> and the algorithm-ids like SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE
> are ignored. That leads to error Messages from cmsutil.
>
> So I wonder, to which RFC the CMS in NSS is compliant.
Could you provide exact steps needed to reproduce this?
--
Regards,
Hubert Kario
Senior Quali
On Wednesday 13 January 2016 17:43:02 Kai Thiele wrote:
> Hubert Kario redhat.com> writes:
> > On Monday 11 January 2016 15:53:26 Kai Thiele wrote:
> > > Hi,
> > >
> > > regarding CMS (Cryptographic Message Syntax),
> > > which RFC is the current
an confirm the bug. Will you file a bug in mozilla bugzilla
against the NSS component?
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a dig
changes summary: 0 Removed, 0 Changed (4 filtered out), 1 Added
function
Variables changes summary: 0 Removed, 1 Changed, 0 Added variable
1 Added function:
'function SECStatus SSL_SetDowngradeCheckVersion(PRFileDesc*, PRUint16)'
{SSL_SetDowngradeCheckVersion@@NSS_3.2
ay to handle API changes.
I'm sorry Ryan, but I also don't see how this would break API.
Stuff that didn't work previously and now will work is not something I
would consider API or ABI break.
I see David argumentation as completely valid and correct - this is
acceptable change.
--
Regard
On Tuesday 05 April 2016 07:26:56 Ryan Sleevi wrote:
> On Tuesday, April 5, 2016, Hubert Kario wrote:
> > On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote:
> > > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse
> > > >
> > I'm sorry Ryan, but
>> list archive at Nabble.com. --
> >> dev-tech-crypto mailing list
> >> dev-tech-crypto@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-tech-crypto
> >
> > --
> > dev-tech-crypto mailing list
> > dev-tech-crypto@lists.mozilla.org
olution as
> opposed to the *relative* complacency we are seeing now.
I don't think we are in the position to demand crypto community to do
anything in particular...
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r
assout pass: -out localhost.p12 -inkey localhost.key
-in localhost.crt
pk12util -i localhost.p12 -d sql:nssdb/ -W ''
certutil -L -d sql:nssdb/ -n localhost -a | openssl x509 -noout -text
so it doesn't look to me like a problem with EC keys specifically
which version of OpenSSL a
On Wednesday 29 June 2016 12:45:40 Chris Richardson wrote:
> On 29 June 2016 at 12:02, Hubert Kario wrote:
>
> > On Tuesday 28 June 2016 02:59:18 chrisr wrote:
> > > Hi,
> > >
> > > I'm trying to import an EC key and cert generated with openssl into a
can you provide exact commands and their outputs you have used?
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
--
-r or -a
the resulting PEM or DER file can be converted to PKCS#12 file with `openssl
pkcs12` utility
>
> -Original Message-
> From: Hubert Kario [mailto:hka...@redhat.com]
> Sent: Friday, January 20, 2017 7:11 AM
> To: dev-tech-crypto@lists.mozilla.org
> Cc: Yao,
a bit, we should be lenient for signatures made by end-user
software and strict for signatures made by CA software.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
De
7c0f9e162bce33576b315ececbb6406837bf51f5
then 1 *is* your private key value (I don't think I have to explain how bad
that is...)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Rep
illa.org/en-US/about/governance/policies/security-group/
certs/policy/
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
; > other party?
> >
> > I would call this a serious breach of security in the NSS public API.
> >
> >
> > --
> > Johann | email: invalid -> com | www.myrkraverk.com/blog/
> > I'm not from the Internet, I just work there. | twitter: @myrkrav
ing NSS 3.35.
> >
> > With my testing, it is not allowed to import multiple certificates with
> > same subject and different nicknames to a certificate database via
> > pk12util. I just want to confirm this point.
> >
> > Best regards,
> > John Jiang
--
R
ween openssl and NSS
implementation of PKCS#12 with regards to AES encryption
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed mes
all that sounds like something that will be very painful to do in multiple
libraries; having to support two, not just one legacy implementation when the
migration happens to TLS doesn't seem to me as something that will help with
that (not to mention that leaving such dead and
hake. In latter case
> Firefox responds with plain text SNI extension (same hostname) in
> second ClientHello, instead of ESNI. Still, handshake successfully
> finishes. Is it intended behavior?
that sounds to me like a question to the IETF TLS mailing list
--
Regards,
Hubert Kario
Senio
therefore does not accept liability for any loss or
damage from receipt or use thereof which arises as a result of internet
transmission. Any views/opinions expressed within this e-mail and any
attachments are that of the individual and not necessarily that of TAS
Solutions Ltd.
--
Regards,
Hubert
45 matches
Mail list logo
