hereof 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 Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat
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
Senior Qua
at 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 already vulnerable code is a
huge liabi
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 message part.
--
dev-t
; I'm using 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,
> > J
to detect proper termination by the
> > 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. |
/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.
--
dev-tech-crypto
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 Republic
t 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
Description: This is a digitally
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, Julie <
On Wednesday 29 June 2016 12:45:40 Chris Richardson wrote:
> On 29 June 2016 at 12:02, Hubert Kario <hka...@redhat.com> wrote:
>
> > On Tuesday 28 June 2016 02:59:18 chrisr wrote:
> > > Hi,
> > >
> > > I'm trying to import an EC key and cert generated
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.o., Purkyňova 99/71, 612 45, Brno,
e Mozilla - Cryptography mailing
> >> 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 lis
On Tuesday 05 April 2016 07:26:56 Ryan Sleevi wrote:
> On Tuesday, April 5, 2016, Hubert Kario <hka...@redhat.com> wrote:
> > On Monday 04 April 2016 12:17:08 Ryan Sleevi wrote:
> > > On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse
> > > <dw...@infradead.org
an, 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.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE
hanged to 'const
PRUint16[74] SSL_ImplementedCiphers' at sslenum.c:49:1:
size of symbol (in bytes) changed from 142 to 148
type of variable changed:
'const PRUint16[71]' changed to 'const PRUint16[74]'
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security te
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 digitally sig
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 cur
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 Quality Enginee
ith 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/tomato42/tlsfuzzer
--
).
--
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.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https
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
that this will make this number effectively only
RC4 over any and all ciphers).
--
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.
--
dev-tech-crypto mailing list
dev
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.
--
dev-tech-crypto mailing list
dev-tech
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 hka...@redhat.com wrote:
The number of sites that prefer RC4 while
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:
* curves weaker than
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
does the right thing.
What if all
?
--
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
as such bugs that cause it fixed. Yes
On Wednesday 22 October 2014 00:59:53 Brian Smith wrote:
On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario hka...@redhat.com 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
changing
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
://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
: 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,
Hubert Kario
--
dev-tech-crypto mailing
without RC4)
On Thu, Jul 10, 2014 at 5:00 AM, Hubert Kario hka...@redhat.com wrote:
- Original Message -
From: Brian Smith br...@briansmith.org
snip
However, it is likely that crypto libraries that make the two changes
above
will also have support for TLS_ECDHE_*_WITH_AES_*_GCM
, Hubert Kario hka...@redhat.com wrote:
Also, see Gavin's email here about adding such prefs in general. He
basically says, Don't do it. Note that Gavin is the Firefox module
owner:
https://groups.google.com/d/msg/mozilla.dev.platform/PL1tecuO0KA/e9BbmUAcRrwJ
As Benjamin notes,
an add
haven't fixed their servers after
Heartbleed (0.5%) or the CCS vulnerability (9%)[1]!
Over 1% of servers still support SSL3 only[2]!
1 - https://www.trustworthyinternet.org/ssl-pulse/
2 - http://wp.me/p4BPwe-x
--
Regards,
Hubert Kario
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
- Original Message -
From: Kurt Roeckx k...@roeckx.be
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:
The benefits of ECDHE outweigh
, Hubert Kario hka...@redhat.com wrote:
Because of that, disabling RC4 should be possible for many users. The big
exception for that was YouTube video servers[4] which only recently gained
support for TLS_RSA_WITH_AES_128_GCM_SHA256.
Hi,
I read your blog post at
http
://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
39 matches
Mail list logo
