RE: Best practice for client cert name checking
From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton
Sent: Saturday, 06 October, 2012 19:11
On Sat, Oct 6, 2012 at 5:41 PM, Charles Mills
charl...@mcn.org wrote:
Thanks. I'm a relative newbie to this whole topic. Can you
point me to a resource that describes pin in the sense you
use it below? The word is too common for the Google to be much help.
If you are using RSA, then the public key is {e,n}. When a client
connects to a server, the client ensures the {e,n} in the server's
certificate is expected. You can usually find it at certificate[0]. In
essence, you have white listed the {e,n} pair for the host in
question.
If using ECC, you have two items to verify: the [public] point and
domain parameters. For prime fields, the public key is the point, Q
(or (qx, qy)), and the domain parameters are {p, a, b, G, n, h} (G is
a base point and sometimes denoted as (gx,gy) pair). Again, its a
whitelist of expected values for the host.
In principle yes, but in practice most ECC uses the few parametersets
(curves) established by standards and assigned OIDs which (are used to)
identify them. In this case you need only check the OID.
Similarly for classic DSA, you have publickey y and parameters
consisting of large prime p, medium subgroup order q and its
generator g. p,q,g can be shared and could be standardized but
to my knowledge aren't. p,g for classic DH also can be standardized
and were in some cases like ssh and IPsec but AFAIK not for SSL,
and any DH for SSL is rare and static-DH not supported by openssl.
If you are using ephemeral key exchanges, then certificate[0] will be
a temporary, throw away key. Ephemeral is good because it provides
forward secrecy. In this case, the server's certificate/public key is
used for authentication, and the public key of interest can be found
at certificate[1]. certificate[1] must sign certificate[0] (some hand
waiving since certificates can't sign one another).
Not in SSL. If you use *static* DH or ECDH, you have that key in cert[0],
which is authenticated by cert[1], and cert[1] further chained as needed.
But as above openssl doesn't support static-DH; it does do static-ECDH,
but I've never seen that used. If you use *ephemeral* those keys are
in separate messages (ServerKeyExchange and/or ClientKeyExchange) not
in any cert. If you use anonymous, again the keys are in S,CKeyExchnage
and there are no certs in the handshake at all.
Yes, ephemeral either DH-E or ECDH-E does have the advantage of forward
secrecy -- but warning, current Java's standard implementation (JSSE)
on server for DH-E uses 768-bit, which isn't adequately secure when used
much less forward. (For ECDH-E most if not all named curves are okay,
and can be limited by the client, and maybe preferred, I'm not sure.)
Other protocols can be different, but it would be impractical to get
valid certs for ephemeral keys unless you are your own online CA, and
then it really give better assurance than using a (static signing) cert
to authenticate the bare key as SSL does.
A certificate, or a publickey, doesn't actually sign anything; the
corresponding privatekey does. But a certificate can carry, and be
marked in KU and/or EKU as carrying, the public half of a privatekey
used to sign certs, CRLs, data, email, etc. Which is what people
mean when they say this, and not really confusing or ambiguous.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: simple server with using openssl
From: owner-openssl-us...@openssl.org On Behalf Of Matthias Apitz Sent: Sunday, 07 October, 2012 02:36 El día Saturday, October 06, 2012 a las 01:37:06PM -0400, Indtiny s escribió: Hi, Thanks for the information .. I get the server part from the this link http://www.rtfm.com/openssl-examples/ I started the server but I am getting the following error when I am trying You did not say exactly which 'server' you started, perhaps the 'wserver' from the openssl-examples-20020110 run the client by $curl http://127.0.0.1:8080 you should use an SSL client, for example 'wclient' from the examples or the openssl' s_client; Or, if it's a web/https server, curl with https://whatever . Aside: port 8080 for https is confusing, that's often used (though not reserved) for http-clear. 8443 would be better. AT the server side : 3078153864:error:140EC0AF:SSL routines:SSL2_READ_INTERNAL:non sslv2 initial packet:s2_pkt.c:187: I think this is normal, because you did not contacted the server with some SSL client; Also it appears this server is doing only SSLv2. That's a bad idea nowadays; although SSLv2 was thought good enough in its day, flaws have since been found; some clients (notably Java) and most if not all scans (and checklists) may refuse it, or at least warn noisily. Get a server that does at least SSLv3, and TLSv1.0 is better. TLSv1.1 or v1.2 is better yet, but in openssl only in 1.0.1, and not yet too widespread in clients. (Of course openssl server can support a range, selecting whatever each client needs.) At the client side : curl: (56) Recv failure: Connection reset by peer normal too; __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How to place signature into an X509 format
From: owner-openssl-us...@openssl.org On Behalf Of redpath Sent: Saturday, 06 October, 2012 18:59 I have created EC Digital Signature and saved it in a file. snip And I use this signature file to verify a message digest later using a public key. snip You don't say, but I assume this signature is on the hash of some data of yours (presumably SHA1 or RIPEMD since it's 20 bytes). Everything works great. I want this signature to be in an X509 and open the X509 and extract it to use to verify things. That makes no sense. An X.509 certificate contains, and binds, some identity (typically the name of a person, organization, or system), to a public-key, for a specified time period optionally (but usually) with related attributes such as allowed usage and revocation checking information, guaranteed by a CA. It doesn't contain any signature on user data. What can make sense is to use a cert to contain, and convey, your publickey. You -- or more usefully someone else, generically called a relier -- can then use the key from the cert to verify a given signature matches given data, and also use the other data in the certificate to decide if the verified data comes from someone the relier wants to trust, and thus to trust that data. How do you place a signature in an X509 format and use code to extract them? In the past I have created an X509 for public keys before and extract the key to use it; and that works great to extract them and use them. Exactly. That's what X.509 cert is for. If you want a standard message format to convey data with a signature, or a signature detached from data, try CMS (Cryptographic Message Syntax) formerly known as PKCS#7. So if anyone has a procedure for the using the API to do this let me know. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Best practice for client cert name checking
On 06.10.2012 23:41 , Charles Mills charl...@mcn.org wrote: Thanks. I'm a relative newbie to this whole topic. Can you point me to a resource that describes pin in the sense you use it below? The word is too common for the Google to be much help. try searching for certificate pinning. If you are familiar with ssh, it is the same concept of the StrictHostKeyChecking option (although obviously SSH and TLS are completely distinct protocols and by default SSH doesn't use X.509 certs). The idea is: with a standard TLS connection, acting as TLS client, you connect to an host for the first time and you receive its certificate. The standard TLS verifications are successful (meaning: the certificate really belongs to the host and it has been issued by a CA you trust). When the connection is closed, a normal TLS client will forget the certificate. On the other hand, certificate pinning remembers the certificate. Pinning means storing locally such certificate and associate it to the hostname you connected to. If the next time you connect the certificate has changed, a system supporting certificate pinning will warn you. The certificate can change for many reasons, some legitimate (e.g. it has expired), some others _might_ be symptom of an attack (e.g. the issuing CA has changed). The assumption behind is that the first time you connect, there is no attack underway, and you store the legitimate certificate. Again with the ssh parallel, ssh stops and shows you the fingerprint of the public key. You are supposed to verify, out-of-band, the fingerprint and then authorize to pin the public key. The criteria to do the verification are up to you. You still have the problem of deciding how to handle the case of certificate changed, but at least you know it is happening. As a parallel: we first meet and as a proof of identity I show you my Italian passport. If the next time we meet you remember me, but this time I show you a French passport, you begin to wonder. Did I change nationality (possible) or is something fishy going on? marco
RE: Best practice for client cert name checking
Dave, any thoughts on my original question? My thread kind of got hi-jacked. Charles -Original Message- From: Charles Mills [mailto:charl...@mcn.org] Sent: Saturday, October 06, 2012 9:52 AM To: openssl-users@openssl.org Subject: Best practice for client cert name checking I have recently written a product that incorporates SSL/TLS server code that processes client certificates. I designed what I thought made sense at the time but now I am wondering if what I did was best. In the product's configuration file the sysadmin may optionally include a whitelist of client names. If the sysadmin does so, then the server requests a client certificate. At least one of the names (subject O= and Alternative names, including wildcards) in the certificate must match one of the names in the whitelist or I reject the session. Something I saw recently got me to wondering whether I should have made some sort of provision for checking IP addresses: perhaps verifying that the client IP address appeared in the Alternative names in the client certificate as well as in the whitelist? Or perhaps that the IP address matched an alternative name and the subject name appeared in the whitelist? Comments? Charles __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Best practice for client cert name checking
On Mon, Oct 08, 2012 at 07:42:04AM +, Marco Molteni (mmolteni) wrote: try searching for certificate pinning. If you are familiar with ssh, it is the same concept of the StrictHostKeyChecking option (although obviously SSH and TLS are completely distinct protocols and by default SSH doesn't use X.509 certs). The idea is: with a standard TLS connection, acting as TLS client, you connect to an host for the first time and you receive its certificate. The standard TLS verifications are successful (meaning: the certificate really belongs to the host and it has been issued by a CA you trust). When the connection is closed, a normal TLS client will forget the certificate. On the other hand, certificate pinning remembers the certificate. Pinning means storing locally such certificate and associate it to the hostname you connected to. If the next time you connect the certificate has changed, a system supporting certificate pinning will warn you. I believe this is what the Certificate Patrol plugin for Firefox is doing, if you want to see it in action. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpbBheOvp6Xv.pgp Description: PGP signature
Re: Best practice for client cert name checking
On Mon, Oct 8, 2012 at 9:25 AM, Mark H. Wood mw...@iupui.edu wrote: On Mon, Oct 08, 2012 at 07:42:04AM +, Marco Molteni (mmolteni) wrote: try searching for certificate pinning. If you are familiar with ssh, it is the same concept of the StrictHostKeyChecking option (although obviously SSH and TLS are completely distinct protocols and by default SSH doesn't use X.509 certs). The idea is: with a standard TLS connection, acting as TLS client, you connect to an host for the first time and you receive its certificate. The standard TLS verifications are successful (meaning: the certificate really belongs to the host and it has been issued by a CA you trust). When the connection is closed, a normal TLS client will forget the certificate. On the other hand, certificate pinning remembers the certificate. Pinning means storing locally such certificate and associate it to the hostname you connected to. If the next time you connect the certificate has changed, a system supporting certificate pinning will warn you. I believe this is what the Certificate Patrol plugin for Firefox is doing, if you want to see it in action. This plug-in pins certificates (not public keys), and creates a lot of spurious noise on some sites (for example, Google and Gmail). It desensitizes the user. I've been running experiments on Google and Gmail for the last couple of years. If you are pinning for those sites, you definitely want to pin public keys. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Memory usage on openssl-0.9.8a/
Team, We used openssl-0.9.8a version of openssl for the SSL communication, for our desktop based TCP application. When we enable it, looks like the memory growth was alarming around 30 times than normal which is really huge. Can someone throw lights on this version or any known memory leaks here ? Please advise. Thanks Regards Karthikeyan Thirumal ADD-Web-NXP-India, Application Development Delivery iNautix Technologies India Private Limited, an affiliate of Pershing LLC, a subsidiary of The Bank of New York Mellon Corporation http://www.inautix.co.in VOIP: 5112 ( 612-5112 ) Email: kthiru...@inautix.co.in Information Classification: Internal Use Only ** This message and any files or attachments sent with this message contain confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute, copy or use any part of this email. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return Email. Email transmission cannot be guaranteed to be secure or error-free as information can be intercepted, corrupted, lost, destroyed, late, incomplete or may contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission. **
RE: Best practice for client cert name checking
Aren't you talking here about the client's validation of the server's credentials? That's useful information, but my question was about server validation of client certificates ... Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Monday, October 08, 2012 11:13 AM To: OpenSSL Users List Subject: Re: Best practice for client cert name checking On Mon, Oct 8, 2012 at 9:25 AM, Mark H. Wood mw...@iupui.edu wrote: On Mon, Oct 08, 2012 at 07:42:04AM +, Marco Molteni (mmolteni) wrote: try searching for certificate pinning. If you are familiar with ssh, it is the same concept of the StrictHostKeyChecking option (although obviously SSH and TLS are completely distinct protocols and by default SSH doesn't use X.509 certs). The idea is: with a standard TLS connection, acting as TLS client, you connect to an host for the first time and you receive its certificate. The standard TLS verifications are successful (meaning: the certificate really belongs to the host and it has been issued by a CA you trust). When the connection is closed, a normal TLS client will forget the certificate. On the other hand, certificate pinning remembers the certificate. Pinning means storing locally such certificate and associate it to the hostname you connected to. If the next time you connect the certificate has changed, a system supporting certificate pinning will warn you. I believe this is what the Certificate Patrol plugin for Firefox is doing, if you want to see it in action. This plug-in pins certificates (not public keys), and creates a lot of spurious noise on some sites (for example, Google and Gmail). It desensitizes the user. I've been running experiments on Google and Gmail for the last couple of years. If you are pinning for those sites, you definitely want to pin public keys. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Best practice for client cert name checking
On Mon, Oct 8, 2012 at 3:49 PM, Charles Mills charl...@mcn.org wrote: Aren't you talking here about the client's validation of the server's credentials? That's useful information, but my question was about server validation of client certificates ... It cuts both ways. Both the client and server can perform the additional validations. Jeff -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Monday, October 08, 2012 11:13 AM To: OpenSSL Users List Subject: Re: Best practice for client cert name checking On Mon, Oct 8, 2012 at 9:25 AM, Mark H. Wood mw...@iupui.edu wrote: On Mon, Oct 08, 2012 at 07:42:04AM +, Marco Molteni (mmolteni) wrote: try searching for certificate pinning. If you are familiar with ssh, it is the same concept of the StrictHostKeyChecking option (although obviously SSH and TLS are completely distinct protocols and by default SSH doesn't use X.509 certs). The idea is: with a standard TLS connection, acting as TLS client, you connect to an host for the first time and you receive its certificate. The standard TLS verifications are successful (meaning: the certificate really belongs to the host and it has been issued by a CA you trust). When the connection is closed, a normal TLS client will forget the certificate. On the other hand, certificate pinning remembers the certificate. Pinning means storing locally such certificate and associate it to the hostname you connected to. If the next time you connect the certificate has changed, a system supporting certificate pinning will warn you. I believe this is what the Certificate Patrol plugin for Firefox is doing, if you want to see it in action. This plug-in pins certificates (not public keys), and creates a lot of spurious noise on some sites (for example, Google and Gmail). It desensitizes the user. I've been running experiments on Google and Gmail for the last couple of years. If you are pinning for those sites, you definitely want to pin public keys. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
