e, I have those disabled because I use the same account for both my
personal and my work projects so no single email address is correct for them
--
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,
es as long as it does when using email
email clients are designed to handle hundreds to thousands of messages a day,
Github UI isn't
or to put it other way: github notifications are perfect if you are directly
involved in the project, they suck if you just want to keep tabs on an active
projec
, 7:00 AM, "Hubert Kario" <hka...@redhat.com> wrote:
>
> On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev
> wrote:
> > There’s a new blog post at
> >
> > https://www.openssl.org/blog/blog/2018/01/18/f2f-london/
>
>
e bigger picture, before getting bogged down in the
> weeds of line-by-line code reviews.
does that mean I have to subscribe to all notifications from the openssl
github project to notice them? that's really suboptimal
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web
fterthought, but they got out of their way to use "more
secure" (debatable) option?
sorry, that does not hold water
--
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
(0003)
> TLS server
> extension "renegotiation info" (id=65281),
> len=1
> 0001 -
> TLS server extension "EC point
> formats" (id=11), len=4
> - 03 00 01
> 02
>
> TLS server extension &
ly)
removing any PSKs which are incompatible with the server's
indicated cipher suite.
--
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 i
On Thursday, 31 August 2017 11:13:13 CEST Richard Levitte wrote:
> In message
>
penssl
> > app. levitte> All our other uses of lhash use their own hashing
> > functions, and are levitte> usually very short still (definitely less
> > than 16 bytes). levitte>
> > levitte> My conclusion is that performance-wise, siphash doesn't give us
> > a
On Friday, 16 September 2016 17:26:03 CET Hubert Kario wrote:
> I've been running tests on the openssl 1.1.0 release recently and I've
> noticed that if the client doesn't include the supported_groups extension,
> OpenSSL will pick curve with id 0x001d, that is ecdh_x25519, as the curv
nse.pro
> ofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dde
> v=DgMDaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAw
> mtRik=xoYIrv5R7W7QHyLEdOuyzFJ-b7mHMoeJeaJ6OXIq3Os=PzZDcf-p6tMpMoz0dw0z21
> yscvoMGdBrpf08ZD7UAq8=>
>
>
>
&g
,
but it is in specifications, and it is essentially set in stone by already
deployed implementations
any kind of departure from this behaviour is likely to cause interoperability
failures (and they will be blamed on OpenSSL as it was the last thing that
changed...)
--
Regards,
Hubert K
's not what I was talking about
I'm talking only about the case of "no curves advertised at all" i.e.
supported_groups extension missing completely from client hello
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky
x25519 (given how new it is).
--
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.
--
openssl-dev mailing list
On Thursday, 11 August 2016 13:50:53 CEST Sebastian Andrzej Siewior wrote:
> On 2016-08-11 11:34:24 [+0200], Hubert Kario wrote:
> > it all depends on the environment, in some renegotiation is completely
> > unnecessary (public HTTP servers without client certificate based
>
r HTTP with client certificates), while in other
still renegotiation is necessary for both sides (long sessions that want the
ability to renew encryption keys).
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky
the system, and
mix it all together and then use output of a DRBG that uses all that entropy
to seed other DRBGs
what that means in practical terms, is feed output from your NDRNG to kernel's
entropy pool and seed everything from /dev/urandom output (or getrandom())
--
Regards,
Hubert Kario
Senior
ling malformed Client Key Exchange
> messages in RSA key exchange
>
> On Fri, Jul 22, 2016 at 10:16:16PM +, David Benjamin via RT wrote:
> > On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT <r...@openssl.org>
> > wrote:
> >
> > > On Friday, 22 July 20
remaster secret that was not provided by the client, instead OpenSSL
just closes the connection
--
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
--
Ticket here: http://rt.openssl.org/T
et in case of problems with CKE message - as it's the same
behaviour OpenSSL, NSS and GnuTLS exhibit
--
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
--
Ticket here: http://rt.openssl
n another terminal, same directory
PYTHONPATH=tlsfuzzer python
tlsfuzzer/scripts/test-invalid-rsa-key-exchange-messages.py
--
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
--
On Friday, 15 April 2016 13:22:52 CEST Hubert Kario via RT wrote:
> Using either current 1.0.1 or 1.0.2 branch (7a433893a and 9676402c3a
> respectively) openssl s_server command does not send Alert message upon
> receiving a malformed or invalid Client Key Exchange message in DHE key
&
On Tuesday, 19 July 2016 23:35:13 CEST Dr. Stephen Henson wrote:
> On Tue, Jul 19, 2016, Hubert Kario wrote:
> > I have few questions now though:
> >
> > I've noticed that 1.0.2 uses sha1 hmac for the PRF while the master
> > uses sha256
> >
> > is ther
is?
also, is there a way to report the MAC algorithm used over the whole
file (the one set using -macalg)
--
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
-ecdhe-rsa-key-exchange-with-bad-messages.py
popd
kill $openssl_pid
--
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
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4610
Timeout : 300 (sec)
Verify return code: 0 (ok)
Keying material exporter:
Label: 'EXPORT-label'
Length: 20 bytes
Segmentation fault (core dumped)
--
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
t;openssl-102-compat" package?
what about Debian CVE-2008-0166 like scenario?
--
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
--
Ticket here: http://rt.openssl.org/Ticket/Displa
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa
PYTHONPATH=. python scripts/test-version-numbers.py
popd
kill $openssl_pid
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňo
t brief says that the SHA-512 *can* be accelerated
which is not part of the ARM cryptographic extensions
it's the X-Gene 2 that says that the optional ARM v8 cryptographic instructions
are supported:
https://myapm.apm.com/technical_documents/download/apm883408-x2-product-brief
my mistake
since I
y that X-Genes do support cryptograpic
extensions:
https://myapm.apm.com/technical_documents/download/apm883208-product-brief1
--
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 Re
g 100524.03k vs 52172.12k/s in favour of the non-EVP
version.
Is that really expected?
With 1.0.1 and 1.0.2 I'm getting around 10k/s with and without
EVP, so that looks like a regression to me.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.co
(24bf6f3c7fccd9)
--
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
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4588
Please log in as guest with password guest if prompted
t; > (48)
it complains, but does it abort connection?
--
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.
--
ope
his question. There are many pieces to the FIPS puzzle, setting the
kernel fips flag is just one item.
Please contact support directly.
--
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
or the future. What's the best way to do that?
until getrandom()/getentropy()[1] is added to glibc, there's little that
openssl can do
1 - https://sourceware.org/bugzilla/show_bug.cgi?id=17252
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat C
y Exchange ...
OK
invalid dh_Yc value - 8192b ...
OK
sanity check DHE_RSA_AES_128 ...
OK
truncated dh_Yc value ...
OK
Test end
successful: 4
failed: 0
--
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, Cz
On Friday 01 April 2016 16:47:57 Brian Reichert wrote:
> On Fri, Apr 01, 2016 at 07:21:13PM +0200, Hubert Kario wrote:
> > So, while it doesn't look like it is vulnerable to DROWN, it doesn't
> > instill a lot of confidence in me...
>
> Thanks for the review.
>
> FWIW,
On Friday 01 April 2016 12:35:49 Brian Reichert wrote:
> On Fri, Apr 01, 2016 at 12:19:21PM +0200, Hubert Kario wrote:
> > On Wednesday 30 March 2016 12:27:47 Brian Reichert wrote:
> > > Each failed conversation yields a 'TLSIllegalParameterException'
> > > error;
TLSIllegalParameterException: Malformed record layer header
> TLSIllegalParameterException: Malformed record layer header
> TLSIllegalParameterException: Malformed record layer header
> TLSIllegalParameterException: Malformed record layer header
> TLSIllegalParameterException: M
rs(1) output? If so, the code needs an exception
> that can otherwise be avoided.
I'd say that ciphers(1) is directed more at human users than on
applications, I don't think changing it there would be a problem.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: w
ority will go to patches with sufficiently complete documentation.
https://github.com/blog/1184-contributing-guidelines
https://github.com/openssl/openssl/blob/master/CONTRIBUTING
it just needs to be updated
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.
re is correct for task at
hand, for now I'm not asking for help on it directly, I'd prefer not to
have to throw away somebody else's months of work because the whole
approach of tlsfuzzer was incorrect...
That being said, I'm open for test ideas.
--
Regards,
Hubert Kario
Senior Quality Engineer, Q
)
In both cases all the individual tests in the scripts should print "OK"
status if the specific cipher is not supported and report "failed: 0"
together with exit status of 0 if you want to automate it.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE Base
t;
> Since many users enable just HIGH ciphers, they must not exclude the
> MTI ciphers.
MTI means Mandatory To Implement, not Mandatory To Deploy or Mandatory
To Enable and definitely does not mean Mandatory To Force User
Applications To Advertise Support For
Nobody on the Interne
g, as that's one of the test scenarios I want to cover in the
tlsfuzzer - verification that server behaviour stays the same no matter
the order of extensions in Client Hello.
1 -
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
--
Regards,
Hubert Kario
Seni
ly so you can't say it is always enabled
in edge cases you will get different chains or validation failures
depending on options set
--
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
-
should be a problem adding
> the support. I'm just not sure about enabling it by default.
I don't think anyone argues that it needs to be added to DEFAULT.
--
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,
out a new mode created by combining
already implemented cipher and integrity mechanism. Mode necessary to
support an ENISA recommended cipher in TLSv1.3.
--
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, Brn
On Tuesday 02 February 2016 21:25:13 Rich Salz via RT wrote:
> Sorry we didn't get to this sooner. We're only taking security fixes
> for 1.0.1 now.
> Is this still an issue? (Hubert?)
courtapps.utcourts.gov:443 is down and myrta.com:443 doesn't show the
problem any more
--
Regard
.
Any error in form of
Unexpected message from peer: Handshake(43)
(or any other number) and an exit value of non-zero means that the
server IS vulnerable.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňo
or RSA, ECDSA and DSA signature inputs.
old proposed patch:
https://github.com/tomato42/openssl/commit/f37b5e639e57c2d4c3b404c24ecb11b8ec627e9b
new proposed patch:
https://github.com/openssl/openssl/commit/02c0d44126cf277a8d51b09863fad55daf74
--
Regards,
Hubert Kario
Senior Quality Engine
les of openssl-users and openssl-dev archives.
> >
> >OK, I've updated the PR: https://github.com/openssl/openssl/pull/554
> >https://github.com/tomato42/openssl/commit/f37b5e639e57c2d4c3b404c24e
> >cb11b 8ec627e9b
> >
> >> Sent from my BlackBerry 10 smartphone
ecb11b8ec627e9b
> Sent from my BlackBerry 10 smartphone on the
> Verizon Wireless 4G LTE network. Original Message
> From: Hubert Kario
> Sent: Monday, January 18, 2016 06:23
> To: openssl-dev@openssl.org
> Reply To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] [
On Thursday 14 January 2016 19:11:54 Blumenthal, Uri - 0553 - MITLL wrote:
> On 1/14/16, 13:56 , "Hubert Kario" <hka...@redhat.com> wrote:
> >On Thursday 14 January 2016 14:41:20 Blumenthal, Uri - 0553 - MITLL wrote:
> >> If you already know what Dr. Hen
On Friday 15 January 2016 14:03:33 Blumenthal, Uri - 0553 - MITLL wrote:
> Yes, and I can live with this update.
Submitted as https://github.com/openssl/openssl/pull/554
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.
correspond to the digest type.
(...)
EXAMPLES
(...)
Sign data using a message digest value (this is currently only
valid for RSA):
openssl pkeyutl -sign -in file -inkey key.pem -out sig -pkeyopt
digest:sha256
->8--
So it looks documented to me. What is missing in
used in the
EVP_get_digestbyname() function for example B.
--
2.4.3
--
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
Descrip
; cat /dev/zero | openssl enc -aes-128-cbc -K $key -iv $iv
>
> is a better way to produce a random stream of arbitrary length,
> it is also hardware accelerated (AESNI) on many systems.
I would upgrade that to aes-128-ctr, but it's not bad per-se
--
Regards,
Hubert Kario
Senior Quality Eng
; cat /dev/zero | openssl enc -aes-128-cbc -K $key -iv $iv
>
> is a better way to produce a random stream of arbitrary length,
> it is also hardware accelerated (AESNI) on many systems.
I would upgrade that to aes-128-ctr, but it's not bad per-se
--
Regards,
Hubert Kario
Senior Quality Eng
re currently the only
> supported.
AES selects both AES-CBC and AES-GCM while AESGCM selects just AES-GCM.
Selecting ChaCha20-Poly1305 by just CHACHA20 is consistent with existing
flags.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
R
On Monday 30 November 2015 16:23:48 Blumenthal, Uri - 0553 - MITLL
wrote:
> On 11/30/15, 11:10 , "openssl-dev on behalf of Hubert Kario"
>
> <openssl-dev-boun...@openssl.org on behalf of hka...@redhat.com>
wrote:
> >On Friday 27 November 2015 13:39:36 Tom Jay
m also biased towards testing _all_ supported
features, not stuff that is 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
Descrip
o figure out what I want to do.
https://wiki.openssl.org/index.php/Main_Page
If you have specific use cases missing from there, please tell, but be
precise
--
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,
o figure out what I want to do.
https://wiki.openssl.org/index.php/Main_Page
If you have specific use cases missing from there, please tell, but be
precise
--
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,
46,507!
are you sure that the negotiated cipher suite is the same and that the
NSS is not configured to reuse the server key share if you're using DHE
or ECDHE?
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyň
tions in which using "broken or outdated"
algorithms is both secure and unavoidable.
See my email from Wed, 18 Nov 2015 14:05:07 +0100.
And to repeat myself: TLS is *not* the only way OpenSSL is used.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.c
>
wrote:
> >> On 11/18/2015 07:05 AM, Hubert Kario wrote:
> >>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
> >>> support
> >>> both relatively modern TLS with user certificates, preferably the
> >>> newest
&
On Wednesday 18 November 2015 11:12:59 Benjamin Kaduk wrote:
> On 11/18/2015 07:05 AM, Hubert Kario wrote:
> > So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
> > support both relatively modern TLS with user certificates,
> > preferably the newest cryptosyste
a hurdle they simply can't cross.
And this also allows openssl to change the cryptographic policy in
stable branches without breaking the API/ABI promise. (POODLE, FREAK,
Logjam)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat C
later.
> Thanks,
> Emilia
>
> On Mon, Nov 16, 2015 at 7:25 PM, Hubert Kario <hka...@redhat.com>
wrote:
> > On Monday 16 November 2015 16:51:10 Emilia Käsper wrote:
> > > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves
> > >
> > > This isn't
verifying
> old MD2 signatures on self-signed certs
is not true. I was talking about document signatures, time stamps, CRL
signatures and certificate signatures in general. Not the trust anchors
or their self-signatures.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Looks like rekeying is on the table again for TLSv1.3:
https://www.ietf.org/mail-archive/web/tls/current/msg18295.html
so I'd say this issue should get fixed or at least workarounded (allowed
in case the identity doesn't change)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS
On Monday 09 November 2015 14:41:50 Hubert Kario via RT wrote:
> Looks like rekeying is on the table again for TLSv1.3:
> https://www.ietf.org/mail-archive/web/tls/current/msg18295.html
>
> so I'd say this issue should get fixed or at least workarounded
> (allowed in case the i
On Monday 09 November 2015 17:00:45 Kaduk, Ben via RT wrote:
> On 11/09/2015 08:41 AM, Hubert Kario via RT wrote:
> > Looks like rekeying is on the table again for TLSv1.3:
> > https://www.ietf.org/mail-archive/web/tls/current/msg18295.html
>
> The proposed rekeying mechanis
being negotiated from state for the current epoch. We
> could probably patch things up to work around these two specific
> examples but I worry that without the more significant refactoring
> work, we may open ourselves up to other attacks that we haven't
> thought of.
unfortunately
enough? Can you infer from context which "Encrypted
> Handshake Message" is what?
yes, thank you, if that exchange is typical, then it's enough to allow
application data between Client Hello and Certificate/Client Key Exchange
to at least "patch up" this issue
--
Regards,
On Friday 16 October 2015 09:55:41 Matt Caswell wrote:
> On 16/10/15 09:53, Matt Caswell via RT wrote:
> > On 13/10/15 12:31, Hubert Kario via RT wrote:
> >> On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote:
> >>> On 12/10/15 17:19, Matt Caswell via RT w
On Friday 16 October 2015 13:52:14 Matt Caswell via RT wrote:
> On 16/10/15 10:56, Hubert Kario via RT wrote:
> > On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote:
> >> So now I really don't know what the "right" way forward is. Should
> &
On Monday 12 October 2015 16:19:43 Matt Caswell via RT wrote:
> On 12/10/15 16:39, Matt Caswell via RT wrote:
> > On 12/10/15 16:03, Alessandro Ghedini via RT wrote:
> >> On Mon, Oct 12, 2015 at 01:45:20PM +, Hubert Kario via RT
wrote:
> >>> On Friday 09 October
e problem.
>
> Ok, updated version of the patch attached. This is for 1.0.2 but
> should pass Hubert's tests even when you run s_server with "-tls1_2".
yup, looks good with -tls1_2 now too
for some reason my side can't negotiate TLS 1.1 or TLS 1.0 correctly so
can't test -tl
On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote:
> On 09/10/15 19:02, Hubert Kario via RT wrote:
> > And for good measure, I also created a test script that
> > combines fragmentation with interleaving.
>
> Did you try my patch with it? And if so what happened?
On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote:
> On 09/10/15 19:02, Hubert Kario via RT wrote:
> > And for good measure, I also created a test script that
> > combines fragmentation with interleaving.
>
> Did you try my patch with it? And if so what happened?
, name:
scripts/test-interleaved-application-data-and-fragmented-handshakes-in-renegotiation.py
run in exact same way as previous ones
--
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
--pre tlslite-ng
git clone https://github.com/tomato42/tlsfuzzer.git
cd tlsfuzzer
PYTHONPATH=. python scripts/test-invalid-session-id.py
--
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 Re
f clients that do send SSLv2 backwards compatible
Client Hello, dropping it completely, even though it allows to
relatively safely negotiate TLS connections, is probably going one step
too far.
I don't plan to work on SSLv2 Client Hello fuzzing in near future
though.
--
Regards,
Hubert Kari
On Thursday 08 October 2015 17:37:12 Viktor Dukhovni wrote:
> On Thu, Oct 08, 2015 at 04:12:50PM +0000, Hubert Kario via RT wrote:
> > The server does not abort connection upon receiving a Client Hello
> > message with malformed session_id field.
> >
> > Affe
On Friday 02 October 2015 11:51:10 Alessandro Ghedini via RT wrote:
> On Fri, Oct 02, 2015 at 11:26:36am +0000, Hubert Kario via RT wrote:
> > Current git checkout of 1.0.1, 1.0.2 and master accept malformed
> > Client Hello messages.
> >
> > If the client s
erver -key localhost.key -cert localhost.crt -www
in other console:
pip install --pre tlslite-ng
git clone https://github.com/tomato42/tlsfuzzer.git
cd tlsfuzzer
PYTHONPATH=. python scripts/test-truncating-of-client-hello.py
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.
ClientKeyExchange
[ChangeCipherSpec]
Finished
Application Data[1] >
[ChangeCipherSpec]
< Finished
Application Data[2] <---&g
the σ needs to be, likely 1KiB at the very least.
I'd still say that it's just kicking the can down the road.
--
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
De
On Friday 25 September 2015 19:19:12 Kurt Roeckx via RT wrote:
> On Fri, Sep 25, 2015 at 04:23:27PM +0000, Hubert Kario via RT wrote:
> > Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange
> > ends up as an extension, possibly multiple ones), and that quantu
On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 02:02:36pm +0000, Hubert Kario via RT wrote:
> > On Friday 25 September 2015 13:55:56 Alessandro Ghedini via RT
wrote:
> > > On Fri, Sep 25, 2015 at 01:20:12pm +, Hubert K
On Friday 25 September 2015 16:33:40 Matt Caswell wrote:
> On 25/09/15 14:19, Hubert Kario wrote:
> > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite
> > branches reject Client Hello messages bigger than 2^14+4 bytes.
>
> Right. The reason for that is that
On Friday 25 September 2015 16:33:40 Matt Caswell wrote:
> On 25/09/15 14:19, Hubert Kario wrote:
> > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite
> > branches reject Client Hello messages bigger than 2^14+4 bytes.
>
> Right. The reason for that is that
sorry, duplicate of #4063, please close
--
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: PGP signature
___
openssl
u mean by that? As we've said with Matt, you can't create a
valid Client Hello bigger than 131396 bytes...
or do you mean that they accept malformed Client Hello messages?
or that they do accept SSLv3 Client Hellos with arbitrary sized junk at
the end?
--
Regards,
Hubert Kario
Quality Engine
On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 04:17:33PM +, Matt Caswell via RT wrote:
> > On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> > > On Fri, Sep 25, 2015 at 03:02:27pm +, Hubert Kario via RT
wrote:
&
On Friday 25 September 2015 11:40:27 Matt Caswell wrote:
> On 25/09/15 11:25, Hubert Kario via RT wrote:
> > On Friday 25 September 2015 10:47:42 Matt Caswell wrote:
> >> However, I have some concerns with the wording of the RFC. It seems
> >> to place no limits wha
while others that it is from old connection.
I'll file that bug as soon as I have a reproducer for it (most likely
today)
--
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
/tlsfuzzer.git
cd tlsfuzzer
PYTHONPATH=. python scripts/test-record-layer-fragmentation.py
--
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
Descript
1 - 100 of 192 matches
Mail list logo
