[openssl-users] test for DROWN CVE

2016-03-03 Thread Sandeep Umesh
Hello

How can anyone test if the server is susceptible to DROWN CVE? 

Possibly one of the methods is to check at https://drownattack.com/#check

Apart from this, will be below command also be useful to verify for the 
impact? - 
$ openssl s_client -connect : -ssl2 


Regards
Sandeep

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] recommended build options

2016-03-03 Thread Viktor Dukhovni
On Thu, Mar 03, 2016 at 02:00:31PM -0500, Jeffrey Walton wrote:

> > Note that "no-comp" is a consequence of "zlib" and "zlib-dynamic"
> > not being enabled.  You have to choose to turn compression on IIRC
> > by enabling one of these.
> 
> no-comp disables compression independent of zlib. OPENSSL_NO_COMP will
> be defined in the OpenSSL headers.

Yes, it overrides these, and I was forgetting that there can perhaps
be additional compression methods in play.  So "no-comp" is reasonably
sensible, unless you're supportting some application where TLS
compression is both safe and required.

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] recommended build options

2016-03-03 Thread Jeffrey Walton
>> > By and large what should be off by default eventually or already
>> > is, but there can be some delay for backwards compatibility.
>> ...
>> > With these you're covered for no-ssl2 no-comp and no weak ciphers.
>>
>> We are using 1.0.2f, no-ssl2 and no-comp do not appear to be defaults in
>> that version.  Should heartbeats be turned off, or have recent version of
>> OpenSSL taken care of any potential weaknesses there?
>
> Yes, you do need to disable "ssl2" in releases prior to 1.0.1s
> and 1.0.2g.
>
> Note that "no-comp" is a consequence of "zlib" and "zlib-dynamic"
> not being enabled.  You have to choose to turn compression on IIRC
> by enabling one of these.

no-comp disables compression independent of zlib. OPENSSL_NO_COMP will
be defined in the OpenSSL headers.

Also see 
https://wiki.openssl.org/index.php/Compilation_and_Installation#Configure_Options.
As interesting ones show up and team members comment on them, they get
added to the list.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] recommended build options

2016-03-03 Thread Viktor Dukhovni
On Thu, Mar 03, 2016 at 08:13:36AM -0500, Wall, Stephen wrote:

> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> > Behalf Of Viktor Dukhovni
> > 
> > By and large what should be off by default eventually or already
> > is, but there can be some delay for backwards compatibility.
> ...
> > With these you're covered for no-ssl2 no-comp and no weak ciphers.
> 
> We are using 1.0.2f, no-ssl2 and no-comp do not appear to be defaults in
> that version.  Should heartbeats be turned off, or have recent version of
> OpenSSL taken care of any potential weaknesses there?

Yes, you do need to disable "ssl2" in releases prior to 1.0.1s
and 1.0.2g.

Note that "no-comp" is a consequence of "zlib" and "zlib-dynamic"
not being enabled.  You have to choose to turn compression on IIRC
by enabling one of these.

-- 
Viktor.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] Developing CA with Openssl library

2016-03-03 Thread Bear Giles
I've written big chunks of a CA in both openssl and java (BouncyCastle). It
has definite benefits since it can be tightly integrated into an existing
infrastructure but does require a fairly deep understanding of both
concepts and implementation details. The actual key management is not that
hard to write once you have that basic knowledge.

However a CA is a lot more than just signing keys and that can be a lot of
work but I think that will be true regardless of whether you're doing new
development with the libraries or using scripts with the command line
program. The command line is fine for small needs but I would definitely
rather use the libraries (C or java) if I had it sitting behind a web or
microservice.

Finally I should point out that Amazon has just released an X.509 key
management system as part of Amazon Web Services. I haven't had a chance to
look at it but it might be easier to implement a front end to it.

Bear

On Wed, Mar 2, 2016 at 11:24 PM, lists  wrote:

> On 03/02/2016 09:36 AM, thirumalkumarkanakur...@bel.co.in wrote:
>
>>
>> Dear users,
>>  I want to develop my own CA with openssl library with all the CA
>> functionalities like Key generation,Certificate creation,Certificate
>> Revocation List creation,Certificate revocation and certificate
>> verification.in Order to do so i am struct with the following questions
>>
>> 1. currently i am using openssl_1_0_1 stable version. With this version
>> is it possible to perform the above operations.
>>
>
> Yes, but it's a lot of code to write if you plan to use the library.
>
> 2. Will above mentioned version provide full CA CRL functionalities.
>>  please help me  with your valuable suggestions and solutions. Thanks in
>> advance.
>>
>>
> For what I know, all of it is there, too.
> But really consider using OpenSSL-based open source products or at least
> openssl command line tools where possible, otherwise it is just as answer
> (1): there is a lot to do!
>
>
> Regards
>> Thirumal Kumar Kanakurthi
>> Member (Research Staff)/NWS Group
>> Central Research Laboratory(BEL).
>> Bangalore.
>> Mobile:+918050469976
>>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


[openssl-users] Need some information about TLS with AES-GCM

2016-03-03 Thread Medulla Oblongata
Hello,
I'm running server and client and they communicate using DTLS over UDP and 
cipher suite in use is AES-GCM-SHA384.
What i want to do here is to decrypt the packets which are sent by the client 
but i keep failing to do so.
To do this i obviously need the clients write key, nonce, the actual encrypted 
data and the additional data like it's specified here 
https://tools.ietf.org/html/rfc5246 in section 6.2.3.3.
The key is the easy part, that i can get from the client. 
Next part is the nonce, which to my understanding and according to this 
https://tools.ietf.org/html/rfc5116 document is built from 2 parts, the 
explicit part which is the first 8 bytes after the UDP header just before the 
ciphertext and the 4 byte salt which is negotiated during the handshake, those 
two are then concatenated (salt + 8bytes of data) and this is then used as a 12 
byte initialization vector.
Then there is the additional data which according to this 
https://tools.ietf.org/html/rfc5246 (section 6.2.3.3) is:seq_num + 
TLSCompressed.type + TLSCompressed.version + TLSCompressed.length
Now, what i would like to do is to use 
https://raw.githubusercontent.com/openssl/openssl/master/demos/evp/aesgcm.c 
this as a template and decrypt the data that's in the packet but when i plug in 
the encrypted data, key, aad and IV it just fails.
The only problem here is with the tag which is used in the example after the 
data is decrypted and before the EVP_DecryptFinal_ex function is called. I 
assume that it is appended to the data before encryption and i have to get it 
after the data is decrypted, is this correct?
So question is, what im doing wrong? Do i derive the IV and additional data 
correctly?-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] recommended build options

2016-03-03 Thread Wall, Stephen
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Viktor Dukhovni
> 
> By and large what should be off by default eventually or already
> is, but there can be some delay for backwards compatibility.
...
> With these you're covered for no-ssl2 no-comp and no weak ciphers.

We are using 1.0.2f, no-ssl2 and no-comp do not appear to be defaults in that 
version.  Should heartbeats be turned off, or have recent version of OpenSSL 
taken care of any potential weaknesses there?

> It may also be reasonable to disable "idea", "seed" and "rc2".

We provide config settings to disable ssl3, idea, and seed, though I think it'd 
probably be safe to drop idea and seed altogether.  I believe heimdal uses rc2, 
which precludes disabling that one.

Thanks
-spw
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users