On 12 October 2015 at 12:08, Matt Caswell via RT wrote:
> Are you using your new GOST
> engine or the one currently in master?
>
Sorry to come in in the middle, but where to get that new GOST engine, that
is not on master now?
Is it on some other branch?
___
Hello,
As noted here:
https://groups.google.com/forum/#!topic/mailing.openssl.dev/Ng3xI7-xZ0E
all version of OpenSSL produce scary warning in nginx logs on every
connect, if GOST TLS used:
[alert] 25532#0: *28 ignoring stale global SSL error (SSL:
error:140DD112:SSL routines:SSL_CERT_DUP:library
Strange, but now on the same machine everything works fine.
Seems it was fluctuations of world ether...
On 21 September 2014 15:08, Andrey Kulikov via RT wrote:
> # uname -a
> Linux deb7 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
> # gcc --version
> gcc-4.7.real (
# uname -a
Linux deb7 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
# gcc --version
gcc-4.7.real (Debian 4.7.2-5) 4.7.2
./config && make && make test
fails with following:
The following command should have some OK's and some failures
There are definitly a few expired certificates
.
Indeed,
Improved version of the patch are in:
[openssl.org #2937] Handshake performance degradation in 1.0.1 and up.
On 9 September 2014 21:16, Rich Salz via RT wrote:
> From an internal review of the patch:
> Contexts are meant to be reused and (for example) reusing the same context
> and
> di
Dmitriy,
Thanks for noticing!
I do not see it either - correcting myself. :-)
You are right - according to
http://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04
CryptoProParamSetA is required in GOST TLS.
But only for content encryption.
Premaster secret encryption could use any other parame
Currently ccgost engine use configured params (s-boxes) when it works in
CFB mode only.
For CNT and IMITO parameters are hardcoded to Gost28147_CryptoProParamSetA
Supplied patch allow ccgost engine to really use parameters, specified
either in config file, or via engine API.
When nothing is confi
> > Well...
> > With this check 'make test' fails with:
> >
> > CMS => PKCS#7 compatibility tests
> > signed content DER format, RSA key: generation error
> > make[1]: *** [test_cms] Error 1
> >
> >
> Can't reproduce that here. Anyone else seeing this?
I saw it on Debian 7 x64, gcc 4.7.2
But an
Well...
With this check 'make test' fails with:
CMS => PKCS#7 compatibility tests
signed content DER format, RSA key: generation error
make[1]: *** [test_cms] Error 1
On 14 April 2014 00:16, Andrey Kulikov wrote:
> In 1.0.1g duplicated check for (!pcerts) where removed.
>
> Had an impression
In 1.0.1g duplicated check for (!pcerts) where removed.
Had an impression that second appearance was check for (!*pcerts) (as in
all other functions).
Return it back.
Patch applied.
0001-Check-pcerts-for-NULL.patch
Description: Binary data
Please find attached two patches, together implementing proper HMAC context
re-initialization instead of full re-creation.
In comparison to openssl-1.0.1c it gives ~10% handshake performance
improvements when some engine-specific MAC are used.
In order to apply patches use command
patch -p1 -i
P
On 11 December 2012 04:00, Stephen Henson via RT wrote:
>
>
I also notice that even the original HMAC version initialises two HMAC
> contexts with the same key. That could be improved by initialising one
> and copying the context across.
>
>
This kind of optimization can be also applied P_hash i
Please find attached patch, introducing two new options for s_server:
one specify maximum number of connections s_server will accept. It will
exit clearly after completing last connection
the other tells s_server to show each completed connection duration and
data transfer rate.
These options exce
Just noticing the wrong goto label in case of EVP_PKEY_CTX_ctrl() failue.
Please find attached corrected patch (gost_server_to_check_ukm_v2.patch)
On 17 April 2011 17:54, Andrey Kulikov wrote:
> According to this document:
>
> http://tools.ietf.org/html/draft-chudov-cryptopro-cptls-04#section-3.
Hello,
In v1.0.1 tls_P_hash() has been changed in comparison to early OpenSSL
versions.
Used hash objects is re-initializing during P_hash calculation.
It looks harmless, but only until we come to hash objects, holding
references to external objects.
E.g. engine-specific hashes, allocating handles
In comparison to 1.0.0, in 1.0.1 the implementation of PRF have been
changed.
In order to supporf TLS 1.1/1.2 features, in file ssl/t1_enc.c, in function
tls_P_hash() calls to HMAC_Init/HMAC_Update/HMAC_Final where replaced by
EVP_DigestSignInit/EVP_DigestSignUpdate/EVP_DigestSignFinal.
As a drawb
On 16 December 2011 02:47, Andy Polyakov via RT wrote:
Attached patch fix the problem on cygwin.
>>> Does it mean that you can in fact confirm that modified speed.c runs
>>> without "hanging"?
>>
>> Yes, modified speed.c, being compiled in the same Cygwin environment
>> as before, runs withou
>> It does complain! :-)
>> Attached patch fix the problem on cygwin.
>
> Does it mean that you can in fact confirm that modified speed.c runs
> without "hanging"?
Yes, modified speed.c, being compiled in the same Cygwin environment
as before, runs without "hanging" for all hashes.
Interesting, wh
>Verify http://cvs.openssl.org/chngview?cn=21845.
This patch helps!
Thanks a lot!
>>> ml
>> Microsoft (R) Macro Assembler Version 10.00.30319.01
>> Copyright (C) Microsoft Corporation. All rights reserved.
>
> Microsoft Assembler gets *very* limited testing and the "official"
> standpoint is to
> Compiler might be
> complaining about some small things, use your judgment to ignore
> warnings or to make it compile.
It does complain! :-)
Attached patch fix the problem on cygwin.
Back-ported to 1.0.0e was not break native Win32 (32 bit, VS10) compilation.
spped_cygwin.patch
Description: B
Checked with 1.0.0e - the same problem.
speed hangs up with md4 md5 mdc2 and sha1, but works well with sha256
sha512 and whirlpool.
I downloaded 8G file via s_server from 1.0.1 snapshot 20111213 - works fine.
(using RC4-SHA chiphersuite)
Seems problem in "speed' itself, or, as Andy mentioned - i
> downloaded 8G file via s_server from 1.0.1 snapshot 20111213 - works fine.
Using RC4-SHA chipthersuite.
__
OpenSSL Project http://www.openssl.org
Development Mailing List o
VisualStudio 2010
> perl Configure VC-WIN32
>ms\do_ms.bat
>nmake -f ms\nt.mak
..
ml /nologo /Cp /coff /c /Cx /Zi /Fotmp32\vpaes-x86.obj
tmp32\vpaes-x86.asm
Assembling: tmp32\vpaes-x86.asm
tmp32\vpaes-x86.asm(491) : error A2070:invalid instruction operands
tmp32\vpaes-x86.asm(527) : e
Tested on two computers.
Both native (i.e. non-VM) Windows7 x64 Professional (without SP1).
One has E8600 CPU, the other is laptop with i5 mobile CPU.
Both has 8G RAM.
Both working stable for a monthes.
No abnormalities, no BSODs.
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Cyg
>
> Can you reproduce it under cygwin gdb? I.e. 'gdb apps/openssl' and then
> at gdb prompt 'run speed sha1'. If yes, ctrl-C and 'info threads'. Then
> 'cont', ctrl-C and 'info threads' few more times. Look at thread #1 at
> all occasions. Where is it caught? Does program counter varies? If it's
>
The same behaviour is for other hashes: md4 md5 mdc2 and sha.
But not for sha256, sha512 and whirlpool - everything is ok with these hashes:
$ ./apps/openssl speed sha512 sha256 whirlpool
OpenSSL 1.0.1-dev xx XXX
built on: Tue Dec 13 08:14:31 RST 2011
options:bn(64,32) rc4(8x,mmx) des(ptr,r
OpenSSL 1.0.1 snaphot 20111211, compiled on Cygwin, no special config options.
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
CPU Code2 Duo E8600
make tests shows:
../util/shlib_wrap.sh ./shatest
test 1 ok
test 2 ok
test 3 ok
../util/shlib_wrap.sh ./sha1test
test 1 ok
test 2 ok
te
> 3) An accellerator device directly supports TLS/SSL record
> encryption/decryption and the handshake operation itself.
>
> We do many bus transactions to the accellerator (and
> possibly system calls into the OS kernel) where we
> could do one, doing every single basic cryptographic
> operation i
First of all - it is not a Microsoft bug.
This is bug in some products, who act as a TLS clients.
Second: what should I describe to customers? :-)
Their programms works with other server, by not with mine.
Is the question still valid?
:-)
On 1 July 2011 12:20, Ben Laurie via RT wrote:
> Why ar
Now it is not possible to disable sending renegotiation_info extension from
server.
The only way to do it - is to disable TLS extension completelly, what may
not be considered as acceptable.
But this is required for compatibility with clients, which can't understand
this extension
(but do require
O-o...
Wrong file attached!
Sorry for this - please find correct file attached.
To apply patch use following command in root of current OpenSSL development
tree:
patch -p1 -l -u -b -i prem_cleanup_gost.patch
On 8 April 2011 17:18, Andrey Kulikov via RT wrote:
> Hello,
>
> There is
Hello,
There is a patches made in the past to cleanse sensitive data, such as
premaster sectes for DH ciphersuites, in pemory.
But is missed for GOST ones.
Please find attached a patch which solve this issue.
Both for server and client.
Also it shorten the distance between premaster generation a
In file "ssl/ssl_ciph.c" static array ssl_cipher_methods declared as having
SSL_ENC_NUM_IDX elements.
SSL_ENC_NUM_IDX = 12, but only 11 elements initialized.
Although it may be not critical, it defenitely a bad practice.
Please find attached file: underinit_ssl_chip_array.patch
It add one more NU
>I prefer more generic method similar to ENGINE_load_ssl_client_cert, i.e. I
need EVP keys,
> corresponding certificates and the certificate chain.
Additional methods has "server" in it's names for the same reason why
"ENGINE_load_ssl_client_cert" has "client" in it.
ENGINE_load_server_certificat
Hello,
Please find file attached: server_cert_from_engine4.patch
This is a patch to allow loading server SSL certificate by ENGINE.
Currently OpenSSL allows loading certificate only from a file.
Loading by specific engine is required for hardware-based engines, which
used their own certificate st
35 matches
Mail list logo
