About self signed certificates
Hi all, I am using a self signed certificate as a CA certificate. My entity certificate is signed by this self signed CA. in my test programs But another programmer who is doing client part is saying I need to include keyUsage field in my self signed certifcate refering to RFC 3280 ( section 4.2.1.3 Key Usage) This extension MUST appear in certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs. But I heard self signed certificates should not have keyUsage field. I want to know the limitation of self signed certicate.. Thanks in advance. -- with regards Subramanaim Engineer Software SCM Microsytems (INDIA) Pvt. Ltd. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
apache 2.2 with openssl problem
Hi i try complie apache with my openssl ./configure --prefix=/usr/unizeto/apache22 --enable-proxy --enable-ssl --with-ssl=/opt/NEW/openssl/ [...] checking for OpenSSL version... checking openssl/opensslv.h usability... yes checking openssl/opensslv.h presence... yes checking for openssl/opensslv.h... yes checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes OK checking openssl/engine.h usability... yes checking openssl/engine.h presence... yes checking for openssl/engine.h... yes checking for SSLeay_version in -lcrypto... no checking for SSL_CTX_new in -lssl... no checking for ENGINE_init... no checking for ENGINE_load_builtin_engines... no checking for SSL_set_cert_store... no configure: error: ... Error, SSL/TLS libraries were missing or unusable -- bash-2.03# cd /opt/NEW/openssl bash-2.03# ls bin include lib ssl any idea ? -- spider[at]linux.[dot].pl
Re: apache 2.2 with openssl problem
checking openssl/engine.h usability... yes checking openssl/engine.h presence... yes checking for openssl/engine.h... yes checking for SSLeay_version in -lcrypto... no checking for SSL_CTX_new in -lssl... no checking for ENGINE_init... no checking for ENGINE_load_builtin_engines... no checking for SSL_set_cert_store... no configure: error: ... Error, SSL/TLS libraries were missing or unusable -- Do you have set LD_LIBRARY_PATH and/or LD_RUN_PATH environment variables before invoking ./configure script to /opt/NEW/openssl/lib ? Or You can modify PKG_CONFIG_PATH to autodetect libraries. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: apache 2.2 with openssl problem
2007/10/3, Piotr [EMAIL PROTECTED]: checking openssl/engine.h usability... yes checking openssl/engine.h presence... yes checking for openssl/engine.h... yes checking for SSLeay_version in -lcrypto... no checking for SSL_CTX_new in -lssl... no checking for ENGINE_init... no checking for ENGINE_load_builtin_engines... no checking for SSL_set_cert_store... no configure: error: ... Error, SSL/TLS libraries were missing or unusable -- Do you have set LD_LIBRARY_PATH and/or LD_RUN_PATH environment variables before invoking ./configure script to /opt/NEW/openssl/lib ? Or You can modify PKG_CONFIG_PATH to autodetect libraries. bash-2.03# echo $LD_LIBRARY_PATH :/usr/local/firebird/lib:/usr/local/firebird/intl:/usr/local/lib:/opt/NEW/openssl/lib/:/opt/nfast/toolkits/hwcrhk/ -- spider[at]linux.[dot].pl
Re: About self signed certificates
On Wed, Oct 03, 2007 at 11:47:33AM +0530, Subramaniam wrote: I am using a self signed certificate as a CA certificate. Post the CA certificate to the list. My entity certificate is signed by this self signed CA. in my test programs Post the entity certificate to the list. But another programmer who is doing client part is saying I need to include keyUsage field in my self signed certifcate refering to RFC 3280 ( section 4.2.1.3 Key Usage) This extension MUST appear in certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs. Here's a typical CA cert, in fact a one of the Thawte root CA certs: Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/[EMAIL PROTECTED] Validity Not Before: Aug 1 00:00:00 1996 GMT Not After : Dec 31 23:59:59 2020 GMT Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/[EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c: 68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da: 85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06: 6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2: 6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b: 29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90: 6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f: 5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36: 3a:c2:b5:66:22:12:d6:87:0d Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE Signature Algorithm: md5WithRSAEncryption 07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9: a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48: 3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88: 4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9: 8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5: e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9: b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e: 70:47 -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to get useful error messages?
Hello everyone,
I modified my code to add the following two lines after initializing the ssl
library with SSL_library_init():
---
RAND_write_file(prngseed.dat);
RAND_load_file(prngseed.dat, -1);
---
And this solved the problem on HPUX.
Now I am facing the same connectivity problem on AIX box. Note that the above
two lines are still there.
strace on the AIX box doesn't give any output at all.
I have no clue why the SSL_connect is failing.
It will be great if anyone could suggest a way to figure out what is going
wrong here.
~ Urjit
- Original Message -
From: Urjit Gokhale
To: openssl-users@openssl.org
Sent: Monday, September 24, 2007 1:48 PM
Subject: How to get useful error messages?
Hi,
I am running an application on HPUX 11i.
The application fails in SSL_connect(). I tried to print the error message
with the following code snippet:
==
ret = SSL_connect(ssl)
if (ret != 1)
{
char *m_file, *m_data;
int m_line = 0 , m_flags = 0;
printf(error code is %d,SSL_get_error(conn-sock-ssl, ret));
printf(errno is %d,errno);
ERR_peek_error_line_data((const char**)(m_file),
m_line,
(const char**)(m_data),
m_flags);
printf(filename: %s\tline :%d\ndata: %s\nflags:
%d,m_file,m_line,m_data,m_flags);
printf(%s\n,ERR_reason_error_string(ERR_peek_error()));
}
==
The error code is 5 (SSL_ERROR_SYSCALL) and errno is 2 (ENOENT).
But the function ERR_peek_error_line_data() fails, and I dont get any
filename / line number etc.
I used tusc on HPUX to trace the calls, and found that SSL_connect fails to
find a random number generator and hence errno is 2.
Here is the relevent part of the trace generated by tusc:
==
open(/tmp/cacert.pem, O_RDONLY|O_LARGEFILE, 0666)
... = 5
ioctl(5, TCGETA, 0x7a005278)
..
ERR#25 ENOTTY
read(5, - - - - - B E G I N C E R T I .., 8192)
... = 1184
read(5, 0x4002a2c0, 8192)
.
= 0
getpid()
..
= 21419 (21418)
getpid()
..
= 21419 (21418)
getpid()
..
= 21419 (21418)
close(5)
..
= 0
send(4, \0\0\006\0\f, 6, 0)
.
= 6
time(NULL)
= 1190620890
getpid()
..
= 21419 (21418)
time(NULL)
= 1190620890
time(NULL)
= 1190620890
getpid()
..
= 21419 (21418)
getpid()
..
= 21419 (21418)
getpid()
..
= 21419 (21418)
open(/dev/urandom, O_RDONLY|O_NONBLOCK|O_NOCTTY, 0)
. ERR#2 ENOENT
open(/dev/random, O_RDONLY|O_NONBLOCK|O_NOCTTY, 040460)
. ERR#2 ENOENT
open(/dev/srandom, O_RDONLY|O_NONBLOCK|O_NOCTTY, 040460)
ERR#2 ENOENT
socket(AF_UNIX, SOCK_STREAM, 0)
...
= 5
connect(5, 0x7a004750, 19)
ERR#2 ENOENT
close(5)
..
= 0
socket(AF_UNIX, SOCK_STREAM, 0)
...
= 5
connect(5, 0x7a004750, 15)
ERR#2 ENOENT
close(5)
RE: public key in the binary
Don't save it in the binary? Regards, Daniel Clusin EnerNOC, Inc. (617)5328154 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Md Lazreg Sent: Wednesday, October 03, 2007 11:04 AM To: openssl-users@openssl.org Subject: public key in the binary Hi, I am encrypting a file using a private key, and my program is decrypting it using the public key compiled in the binary. The question is how to protect my public key against binary analysis within the binary? I do not want someone to replace it with their own public key and hence encrypting my program's input using their private key. Any ideas please? Thanks
public key in the binary
Hi, I am encrypting a file using a private key, and my program is decrypting it using the public key compiled in the binary. The question is how to protect my public key against binary analysis within the binary? I do not want someone to replace it with their own public key and hence encrypting my program's input using their private key. Any ideas please? Thanks
Re: public key in the binary
On Wed, Oct 03, 2007 at 10:04:26AM -0500, Md Lazreg wrote: I am encrypting a file using a private key, and my program is decrypting it using the public key compiled in the binary. Private keys don't encrypt they sign. The public key *verifies*. If you want to encrypt, you use the public key to encrypt, and the holder of the private key can decrypt. The question is how to protect my public key against binary analysis within the binary? I do not want someone to replace it with their own public key and hence encrypting my program's input using their private key. Any ideas please? Sorry, keys are protected by OS permissions of separate key files, or by dedicated hardware that provides access to operations that use key, but not the key itself. If you are protecting data from the user of your application (DRM), you are mostly out of luck. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: public key in the binary
In message [EMAIL PROTECTED] on Wed, 3 Oct 2007 10:04:26 -0500, Md Lazreg [EMAIL PROTECTED] said: mdlazreg I am encrypting a file using a private key, and my program mdlazreg is decrypting it using the public key compiled in the mdlazreg binary. If it isn't an automatic process of some kind, why is the public key compiled into the binary? mdlazreg The question is how to protect my public key against binary mdlazreg analysis within the binary? I do not want someone to replace mdlazreg it with their own public key and hence encrypting my mdlazreg program's input using their private key. Any ideas please? The only viable option to fulfill all those ideas is to keep your binary completely secret and to yourself. Any external exposure will make it possible to reveal how it's used and make it possible for others to use for their own purposes. Of course, you could encrypt parts of the binary, but it requires that you have a key, and the question is where you're going to have that, especially if this is a binary used in some kind of automatic process... Out of curiosity, what's the reason noone should use the binary with their own private/public key pair? Cheers, Richard -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: apache 2.2 with openssl problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Piotr Skwarna schrieb: Hi i try complie apache with my openssl ./configure --prefix=/usr/unizeto/apache22 --enable-proxy --enable-ssl --with-ssl=/opt/NEW/openssl/ [...] checking for OpenSSL version... checking openssl/opensslv.h usability... yes checking openssl/opensslv.h presence... yes checking for openssl/opensslv.h... yes checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes OK checking openssl/engine.h usability... yes checking openssl/engine.h presence... yes checking for openssl/engine.h... yes checking for SSLeay_version in -lcrypto... no checking for SSL_CTX_new in -lssl... no checking for ENGINE_init... no checking for ENGINE_load_builtin_engines... no checking for SSL_set_cert_store... no configure: error: ... Error, SSL/TLS libraries were missing or unusable any idea ? Have a look in the file config.log. There somewhere are the error messages configure got when trying to link a program with libcrypto. Theses error messages tell you what went wrong. It may be that your OpenSSL library requires linking of libraries that configure doesn't know about. (libz comes to mind...) Bye Goetz - -- DMCA: The greed of the few outweights the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHA5Q72iGqZUF3qPYRAsEiAJsEVNPb/EKpGE0FmhDHEsWpTy1v3gCbB2Ba kXrs+8giI/FQEgQVsSSQ5KA= =/N0f -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to get useful error messages?
Hello, I modified my code to add the following two lines after initializing the ssl library with SSL_library_init(): --- RAND_write_file(prngseed.dat); RAND_load_file(prngseed.dat, -1); --- And this solved the problem on HPUX. This is not good solution. You should install PRNG on your HP-UX system. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: public key in the binary
On 10/3/07, Victor Duchovni [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 10:04:26AM -0500, Md Lazreg wrote: I am encrypting a file using a private key, and my program is decrypting it using the public key compiled in the binary. Private keys don't encrypt they sign. The public key *verifies*. If you want to encrypt, you use the public key to encrypt, and the holder of the private key can decrypt. Private keys do encrypt using the function : http://www.openssl.org/docs/crypto/RSA_private_encrypt.html The holder of the private key is me. And it is my application compiled with my public key that will decrypt whatever I have encrypted with my private key. My application will behave differently depending on what it finds in the decrypted information. The question is how to protect my public key against binary analysis within the binary? I do not want someone to replace it with their own public key and hence encrypting my program's input using their private key. Any ideas please? Sorry, keys are protected by OS permissions of separate key files, or by dedicated hardware that provides access to operations that use key, but not the key itself. If you are protecting data from the user of your application (DRM), you are mostly out of luck. I just want to make sure the user does not instrument my application by changing the public key compiled within it. Basically I am looking for some mathematical operations that will scatter my public key around my executable to make it hard to figure it out. Thanks -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: public key in the binary
On Wed, Oct 03, 2007 at 10:42:59AM -0500, Md Lazreg wrote: Private keys do encrypt using the function : http://www.openssl.org/docs/crypto/RSA_private_encrypt.html Of course they do, but when a private key encrypts, it is called signing, because the public key is presumed to be (drum roll...) public i.e. not held in confidence exclusively by a single recipient. So encrypting with a private key yields signatures, not confidentiality. The holder of the private key is me. And it is my application compiled with my public key that will decrypt whatever I have encrypted with my private key. My application will behave differently depending on what it finds in the decrypted information. Are you signing instructions that the application authenticates, and should ignore if not signed by the right key, or sending confidential data for the eyes of the application only? If you are signing, your model is fine, and embedding the public key in the binary is exactly the right thing to do. If you are encrypting, use a symmetric algorithm, the public key algorithm is just confusing you. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: public key in the binary
On 10/3/07, Victor Duchovni [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 10:42:59AM -0500, Md Lazreg wrote: Private keys do encrypt using the function : http://www.openssl.org/docs/crypto/RSA_private_encrypt.html Of course they do, but when a private key encrypts, it is called signing, because the public key is presumed to be (drum roll...) public i.e. not held in confidence exclusively by a single recipient. So encrypting with a private key yields signatures, not confidentiality. Ok I understand. Thanks. The holder of the private key is me. And it is my application compiled with my public key that will decrypt whatever I have encrypted with my private key. My application will behave differently depending on what it finds in the decrypted information. Are you signing instructions that the application authenticates, and should ignore if not signed by the right key, or sending confidential data for the eyes of the application only? If you are signing, your model is fine, and embedding the public key in the binary is exactly the right thing to do. If you are encrypting, use a symmetric algorithm, the public key algorithm is just confusing you. Yes I am signing. And the application will not work unless it is me who signed the input to it. That is why I do not want someone to change the public key within the application, because if they do they will be able to sign the input using their private key and make my application behave the way they want... I need a way to hide the public key in the binary... Thanks -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: public key in the binary
On Wed, Oct 03, 2007 at 10:57:39AM -0500, Md Lazreg wrote: If you are signing, your model is fine, and embedding the public key in the binary is exactly the right thing to do. If you are encrypting, use a symmetric algorithm, the public key algorithm is just confusing you. Yes I am signing. And the application will not work unless it is me who signed the input to it. This is fine, provided you don't also expect the instructions to the application to remain confidential. That is why I do not want someone to change the public key within the application, because if they do they will be able to sign the input using their private key and make my application behave the way they want... This is not possible. Why are you trying to stop the user from replacing the application's trusted key? Is this DRM? DRM is not possible without trusted hardware, and even then is difficult. What problem does preventing the user from fielding a modified application solve? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: public key in the binary
On 10/3/07, Victor Duchovni [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 10:57:39AM -0500, Md Lazreg wrote: Is this DRM? DRM is not possible without trusted hardware, and even then is difficult. Yes it is DRM in a way. I know it is not possible to have a 100% protection using only software. I am only looking to make it a little bit harder by smartly hiding the public key in the application. What problem does preventing the user from fielding a modified application solve? It solves the problem of preventing the user from running my application in a mode they did not pay for. Thanks -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: public key in the binary
On Wed, Oct 03, 2007 at 11:11:26AM -0500, Md Lazreg wrote: On 10/3/07, Victor Duchovni [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 10:57:39AM -0500, Md Lazreg wrote: Is this DRM? DRM is not possible without trusted hardware, and even then is difficult. Yes it is DRM in a way. I know it is not possible to have a 100% protection using only software. I am only looking to make it a little bit harder by smartly hiding the public key in the application. If your users are not technically sophisticated, and the application is aimed at paying business customers and not the general public, it is enough to compile the key into the application. Businesses don't like being caught stealing. If or users are the general public and/or they are strongly motivated to attack the application, then it is only a matter of time... They can usually not only replace the public key, but also simply remove the code that performs the signature checks, ... There are companies selling something called white-box-cryptography. They have keyed self-obfuscating code, where it is difficult to analyze the control flow of the application, and the encryption is built in the structure of the binary rather than merely being data. Their target market is DRM. Perhaps you are looking for something like that. Don't recall any specific names, but the term should get you started in the right direction. This is not an endorsement of the security of their products, I don't know enough to endorse or condemn them. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
CONNECTED(00000003) vs CONNECTED(00000004)
I am trying to debug a problem with the browser prompting for a client certificate, and I used the following to see the details of the SSL negotiation: # openssl s_client -connect *hostname:port* -msg I am testing 2 different scenarios and get basically the same output for both except that the first line of the output is CONNECTED(0003) for one scenario and CONNECTED(0004) for the other scenario. What do the codes 0003 and 0004 mean? This is basically the only different I can see in the output, so I believe this is the key to my problem. To give more background, I have a server where I have configured SSL client certs to be optional. The behavior I want is that when a user makes an SSL connection via their browser, the browser should NOT prompt for a certificate unless the browser has a certificate that is in the list of Acceptable client certificate CA names that is sent by the server. This is working as expected when I go to my server's hostname directly in the browser e.g. https://myserver.com. However, there is also a switch and a load balancer in front of the server, and when I go through those components to get to the server, e.g. https://myswitch.com, then the browser prompts for a certificate, which I do not want it to do. When I do: # openssl s_client -connect myserver.com:443 -msg the output shows CONNECTED(0004) When I do # openssl s_client -connect myswitch.com:443 -msg the output show CONNECTED(0003) Other than that, the output seems to be the same. Any help would be greatly appreciated. Thanks.
Re: public key in the binary
On Wed, 3 Oct 2007, Md Lazreg wrote: On 10/3/07, Victor Duchovni [EMAIL PROTECTED] wrote: On Wed, Oct 03, 2007 at 10:42:59AM -0500, Md Lazreg wrote: Private keys do encrypt using the function : http://www.openssl.org/docs/crypto/RSA_private_encrypt.html Of course they do, but when a private key encrypts, it is called signing, because the public key is presumed to be (drum roll...) public i.e. not held in confidence exclusively by a single recipient. So encrypting with a private key yields signatures, not confidentiality. Ok I understand. Thanks. The holder of the private key is me. And it is my application compiled with my public key that will decrypt whatever I have encrypted with my private key. My application will behave differently depending on what it finds in the decrypted information. Are you signing instructions that the application authenticates, and should ignore if not signed by the right key, or sending confidential data for the eyes of the application only? If you are signing, your model is fine, and embedding the public key in the binary is exactly the right thing to do. If you are encrypting, use a symmetric algorithm, the public key algorithm is just confusing you. Yes I am signing. And the application will not work unless it is me who signed the input to it. That is why I do not want someone to change the public key within the application, because if they do they will be able to sign the input using their private key and make my application behave the way they want... I need a way to hide the public key in the binary... At this point the best you can get is security by obscurity. You can make it hard for the attacker to find the public key but there is no way to make it very hard or impossible to find where and how the public key is stored. You are not going to find some fancy mathematical way to hide this information because no matter what you do your program will have to include algorithm for reassembling it and you are going to give your program (with that algorithm included) to the user. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: public key in the binary
Hello, If your users are not technically sophisticated, and the application is aimed at paying business customers and not the general public, it is enough to compile the key into the application. Businesses don't like being caught stealing. If or users are the general public and/or they are strongly motivated to attack the application, then it is only a matter of time... They can usually not only replace the public key, but also simply remove the code that performs the signature checks, ... There are companies selling something called white-box-cryptography. They have keyed self-obfuscating code, where it is difficult to analyze the control flow of the application, and the encryption is built in the structure of the binary rather than merely being data. Their target market is DRM. Perhaps you are looking for something like that. Don't recall any specific names, but the term should get you started in the right direction. This is not an endorsement of the security of their products, I don't know enough to endorse or condemn them. You may also look at Secure Programming Cookbook for C and C++ chapter 12 with TOC: Chapter 12. Anti-Tampering 12.1 Understanding the Problem of Software Protection 12.2 Detecting Modification 12.3 Obfuscating Code 12.4 Performing Bit and Byte Obfuscation 12.5 Performing Constant Transforms on Variables 12.6 Merging Scalar Variables 12.7 Splitting Variables 12.8 Disguising Boolean Values 12.9 Using Function Pointers 12.10 Restructuring Arrays 12.11 Hiding Strings 12.12 Detecting Debuggers 12.13 Detecting Unix Debuggers 12.14 Detecting Windows Debuggers 12.15 Detecting SoftICE 12.16 Countering Disassembly 12.17 Using Self-Modifying Code but of course this is no real security but this only makes hard software hackers job. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: public key in the binary
On Wed, Oct 03, 2007 at 11:11:26AM -0500, Md Lazreg wrote: What problem does preventing the user from fielding a modified application solve? It solves the problem of preventing the user from running my application in a mode they did not pay for. If your target is PC software, then using dongles is probably the right way to go: the dongle designers are supposed to have thought of the problem in depth. For embedded targets, a company I worked at previously ultimately relied on scrambling the mode with the MAC address of the device in some obscure way and calling that 'the key', which would be computed in-house and given to the customers. Not very secure at all, but like said by Victor, it's probably enough to stop companies (and individuals wouldn't buy that product anyway). Cheers, Y. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: CONNECTED(00000003) vs CONNECTED(00000004)
The switch and load balancer do not have their own SSL server certificate. In the browser, when I view the certificate, I can see that I am getting the SSL certificate from the back-end server myserver. The switch and load balancer SHOULD be configured such that the SSL session terminates at the backend server, rather than at the switch or LB. However, I am definitely suspicious of the switch/LB configuration. I am hoping that finding out the difference between the 0003 and 0004 codes will give me a clue as to what is wrong with the configuration. On 10/3/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Amy, Does your switch / load balancer have it's own SSL certificate? Otherwise, the load balancer would be presenting the myserver.com certificate, which would not match myswitch.com. Also, if the switch / local balancer is protocol based, you might be doing something like: client connects via SSL to switch/balancer which decrypts the packets to examine them, re-encrypts the packets and connects via SSL to myserver.com, so the client SSL connection is really to the switch/balancer, not your true back end. Dan Please respond to openssl-users@openssl.org Sent by:[EMAIL PROTECTED] To: openssl-users@openssl.org cc: (bcc: Dan Mitton/YD/RWDOE) Subject:CONNECTED(0003) vs CONNECTED(0004) LSN: Not Relevant User Filed as: Not a Record I am trying to debug a problem with the browser prompting for a client certificate, and I used the following to see the details of the SSL negotiation: # openssl s_client -connect hostname:port -msg I am testing 2 different scenarios and get basically the same output for both except that the first line of the output is CONNECTED(0003) for one scenario and CONNECTED(0004) for the other scenario. What do the codes 0003 and 0004 mean? This is basically the only different I can see in the output, so I believe this is the key to my problem. To give more background, I have a server where I have configured SSL client certs to be optional. The behavior I want is that when a user makes an SSL connection via their browser, the browser should NOT prompt for a certificate unless the browser has a certificate that is in the list of Acceptable client certificate CA names that is sent by the server. This is working as expected when I go to my server's hostname directly in the browser e.g. https://myserver.com. However, there is also a switch and a load balancer in front of the server, and when I go through those components to get to the server, e.g. https://myswitch.com, then the browser prompts for a certificate, which I do not want it to do. When I do: # openssl s_client -connect myserver.com:443 -msg the output shows CONNECTED(0004) When I do # openssl s_client -connect myswitch.com:443 -msg the output show CONNECTED(0003) Other than that, the output seems to be the same. Any help would be greatly appreciated. Thanks.
Re: CONNECTED(00000003) vs CONNECTED(00000004)
Hello, I am trying to debug a problem with the browser prompting for a client certificate, and I used the following to see the details of the SSL negotiation: # openssl s_client -connect hostname:port -msg I am testing 2 different scenarios and get basically the same output for both except that the first line of the output is CONNECTED(0003) for one scenario and CONNECTED(0004) for the other scenario. What do the codes 0003 and 0004 mean? This is basically the only different I can see in the output, so I believe this is the key to my problem. To give more background, I have a server where I have configured SSL client certs to be optional. The behavior I want is that when a user makes an SSL connection via their browser, the browser should NOT prompt for a certificate unless the browser has a certificate that is in the list of Acceptable client certificate CA names that is sent by the server. This is working as expected when I go to my server's hostname directly in the browser e.g. https://myserver.com. However, there is also a switch and a load balancer in front of the server, and when I go through those components to get to the server, e.g. https://myswitch.com, then the browser prompts for a certificate, which I do not want it to do. Probably this is not request for certificate but DN host name conflict. If your server has CN=myserver.com and your load balancer switches tcp connections then browser connects to myswitch.com but in certificate you have myserver.com and browser is asking you whether it is acceptable. My guess. When I do: # openssl s_client -connect myserver.com:443 -msg the output shows CONNECTED(0004) When I do # openssl s_client -connect myswitch.com:443 -msg the output show CONNECTED(0003) This is tcp socket number/file descriptor. In first case, fd 3 is used for some reason and next fd 4 is allocated. You may look at lsof output for fd 3 usage. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: CONNECTED(00000003) vs CONNECTED(00000004)
Thanks for your comments. I do not think it has anything to do with a DN hostname mismatch. It is true that your browser will give you warning if the CN in the SSL server certificate does not match the hostname you are requesting, but this doesn't affect whether you are prompted for a client certificate. To be sure, I can go to https://ip_address_of_myserver.com and it behaves the same as if I go to https://myserver.com (that is, the browser does not prompt for a client cert). It is only when I go through the switch and load balancer, that it prompts for the client cert. Thanks for the info on the file descriptor. I'll have to look more into this. On 10/3/07, Marek Marcola [EMAIL PROTECTED] wrote: Hello, I am trying to debug a problem with the browser prompting for a client certificate, and I used the following to see the details of the SSL negotiation: # openssl s_client -connect hostname:port -msg I am testing 2 different scenarios and get basically the same output for both except that the first line of the output is CONNECTED(0003) for one scenario and CONNECTED(0004) for the other scenario. What do the codes 0003 and 0004 mean? This is basically the only different I can see in the output, so I believe this is the key to my problem. To give more background, I have a server where I have configured SSL client certs to be optional. The behavior I want is that when a user makes an SSL connection via their browser, the browser should NOT prompt for a certificate unless the browser has a certificate that is in the list of Acceptable client certificate CA names that is sent by the server. This is working as expected when I go to my server's hostname directly in the browser e.g. https://myserver.com. However, there is also a switch and a load balancer in front of the server, and when I go through those components to get to the server, e.g. https://myswitch.com, then the browser prompts for a certificate, which I do not want it to do. Probably this is not request for certificate but DN host name conflict. If your server has CN=myserver.com and your load balancer switches tcp connections then browser connects to myswitch.com but in certificate you have myserver.com and browser is asking you whether it is acceptable. My guess. When I do: # openssl s_client -connect myserver.com:443 -msg the output shows CONNECTED(0004) When I do # openssl s_client -connect myswitch.com:443 -msg the output show CONNECTED(0003) This is tcp socket number/file descriptor. In first case, fd 3 is used for some reason and next fd 4 is allocated. You may look at lsof output for fd 3 usage. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: man in the middle attack over https
On Wed, Oct 03, 2007 at 11:21:46AM -0600, [EMAIL PROTECTED] wrote: Here is the URL they direct the victim too: https://us.etrade.com/login/challange/2b593cba/logon.htm This is not the actual booby-trapped URL that users who click on the phishing links would use. You are not looking at the HTML source of the email. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: public key in the binary
I need a way to hide the public key in the binary... You can't ask in public for a good hiding place. Note that your question has *nothing* to do with OpenSSL or even public key encryption for that matter. Your question is basically how do I make a tamperproof executable. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: public key in the binary
On 10/3/07, David Schwartz [EMAIL PROTECTED] wrote: I need a way to hide the public key in the binary... You can't ask in public for a good hiding place. Note that your question has *nothing* to do with OpenSSL or even public key encryption for that matter. Your question is basically how do I make a tamperproof executable. That is true. The OpenSSL users however are the best suited to answer such questions in my opinion. The suggestion by Marek Marcola to get the book Secure Programming Cookbook for C and C++ is a great one. I have already ordered this book and hopefully I will get some ideas there. Thanks all for your help.
Re: man in the middle attack over https
That's right- nobody can do man-in-the-middle (that I've heard, anyway) on HTTPS, since everything is encrypted using TLS or SSL. If you get extremely lucky and catch the browser at the wrong moment, you can sniff the server key and browser key, but apart from that, it really depends on the strength of the server's key. What they do, is they spoof the certificate and point you to a hijacked webpage (us.etrade.com.mypaidhost.net), from which they can easily collect your login information. They then access your E*Trade account and have lots of fun with it, leaving you holding an empty bag. That's my take on all of this. - Robert On Wed, 2007-10-03 at 15:39 -0400, Victor Duchovni wrote: On Wed, Oct 03, 2007 at 11:21:46AM -0600, [EMAIL PROTECTED] wrote: Here is the URL they direct the victim too: https://us.etrade.com/login/challange/2b593cba/logon.htm This is not the actual booby-trapped URL that users who click on the phishing links would use. You are not looking at the HTML source of the email.
Re: man in the middle attack over https
Thank you very much! I never realised there was even an html attachment! I use mutt and never looked for it. Of course I know why I use mutt and this is one of the reasons why. Since I never looked at the html I never saw the bogus address. How cute eh! These financial instutions have a major major problem. Then they recomend to people to use insecure systems. I expect within a few few years we are going to see some MAJOR hiests! Also IMHO man in the middle is possible even over https. The issue is that you need to create what looks to be a valid cert and this means you need to have what looks to be a valid root CA. The weak link might be updating the Browser's recognised root CA's. I did some work on this a few years back and it looked quite doable to me then but I never actually followed up and looked in detail or looked at the security a browser must implement in order for it to be non-hackable. Its a bit of a catch-22 situtation. If you cannot confirm the validity of the browser's accptable root CA's then I would think one can be chucked in that makes any old self generated cert trustworthy. Again. Thanks for the tip. Again. I never thought to check for html code. On Wed, Oct 03, 2007 at 05:43:22PM -0400, Robert Butler wrote: That's right- nobody can do man-in-the-middle (that I've heard, anyway) on HTTPS, since everything is encrypted using TLS or SSL. If you get extremely lucky and catch the browser at the wrong moment, you can sniff the server key and browser key, but apart from that, it really depends on the strength of the server's key. What they do, is they spoof the certificate and point you to a hijacked webpage (us.etrade.com.mypaidhost.net), from which they can easily collect your login information. They then access your E*Trade account and have lots of fun with it, leaving you holding an empty bag. That's my take on all of this. - Robert On Wed, 2007-10-03 at 15:39 -0400, Victor Duchovni wrote: On Wed, Oct 03, 2007 at 11:21:46AM -0600, [EMAIL PROTECTED] wrote: Here is the URL they direct the victim too: https://us.etrade.com/login/challange/2b593cba/logon.htm This is not the actual booby-trapped URL that users who click on the phishing links would use. You are not looking at the HTML source of the email. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: man in the middle attack over https
Right. With server auth you elimate the weakenss I was thinking about a few years back. As was pointed out I didn't check for html. On Wed, Oct 03, 2007 at 03:55:21PM -0700, Michael Sierchio wrote: [EMAIL PROTECTED] wrote: I'd like to ask the group about a possible man in the middle attack over https. What you've described (though see Viktor's post about what you didn't really include in your message) is not MITM -- it's just a fake URL scheme. SSL v3.0 and TLS with server auth are not subject to MITM. Regards, Michael __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: man in the middle attack over https
On Wed, Oct 03, 2007 at 05:04:52PM -0600, [EMAIL PROTECTED] wrote: These financial instutions have a major major problem. Then they recomend to people to use insecure systems. I expect within a few few years we are going to see some MAJOR hiests! I think you mean a few years ago, but this is off topic for this list, so lets stop here. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: man in the middle attack over https
[EMAIL PROTECTED] wrote: I'd like to ask the group about a possible man in the middle attack over https. What you've described (though see Viktor's post about what you didn't really include in your message) is not MITM -- it's just a fake URL scheme. SSL v3.0 and TLS with server auth are not subject to MITM. Regards, Michael __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: man in the middle attack over https
That isn't man-in-the-middle- that's simple spoofing. And, I never said spoofing wasn't doable. I stated that getting in-between a user and their SSL server depends on the strength of that remote server's SSL cert, or catching the client and server when they're about to start the exchange of temporary keys (so that SSL session will work properly.) - Robert On Wed, 2007-10-03 at 17:04 -0600, [EMAIL PROTECTED] wrote: Thank you very much! I never realised there was even an html attachment! I use mutt and never looked for it. Of course I know why I use mutt and this is one of the reasons why. Since I never looked at the html I never saw the bogus address. How cute eh! These financial instutions have a major major problem. Then they recomend to people to use insecure systems. I expect within a few few years we are going to see some MAJOR hiests! Also IMHO man in the middle is possible even over https. The issue is that you need to create what looks to be a valid cert and this means you need to have what looks to be a valid root CA. The weak link might be updating the Browser's recognised root CA's. I did some work on this a few years back and it looked quite doable to me then but I never actually followed up and looked in detail or looked at the security a browser must implement in order for it to be non-hackable. Its a bit of a catch-22 situtation. If you cannot confirm the validity of the browser's accptable root CA's then I would think one can be chucked in that makes any old self generated cert trustworthy. Again. Thanks for the tip. Again. I never thought to check for html code. On Wed, Oct 03, 2007 at 05:43:22PM -0400, Robert Butler wrote: That's right- nobody can do man-in-the-middle (that I've heard, anyway) on HTTPS, since everything is encrypted using TLS or SSL. If you get extremely lucky and catch the browser at the wrong moment, you can sniff the server key and browser key, but apart from that, it really depends on the strength of the server's key. What they do, is they spoof the certificate and point you to a hijacked webpage (us.etrade.com.mypaidhost.net), from which they can easily collect your login information. They then access your E*Trade account and have lots of fun with it, leaving you holding an empty bag. That's my take on all of this. - Robert On Wed, 2007-10-03 at 15:39 -0400, Victor Duchovni wrote: On Wed, Oct 03, 2007 at 11:21:46AM -0600, [EMAIL PROTECTED] wrote: Here is the URL they direct the victim too: https://us.etrade.com/login/challange/2b593cba/logon.htm This is not the actual booby-trapped URL that users who click on the phishing links would use. You are not looking at the HTML source of the email. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: man in the middle attack over https
On Wed, Oct 03, 2007 at 07:57:41PM -0400, Robert Butler wrote: That isn't man-in-the-middle- that's simple spoofing. I would like to humbly suggest that this thread end... Phishing attacks can be discussed on other lists. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: man in the middle attack over https
Indeed, I had planned on clamming up after that last post. - Robert On Wed, 2007-10-03 at 22:17 -0400, Victor Duchovni wrote: On Wed, Oct 03, 2007 at 07:57:41PM -0400, Robert Butler wrote: That isn't man-in-the-middle- that's simple spoofing. I would like to humbly suggest that this thread end... Phishing attacks can be discussed on other lists.
Re: CONNECTED(00000003) vs CONNECTED(00000004)
Figured out the problem: Internet Explorer. I should have guessed. In IE's security settings, the default for the Internet zone has the setting Don't prompt for client certificate when no certificates or only one certificate exists set to Disabled. However, the default for the Local intranet zone has that set to Enabled. From the browser I was testing with, https://myserver.com was part of the Local intranet zone, so IE didn't prompt for a client certificate. https://myswitch.com was part of the Internet zone, so IE did prompt for a client certificate. So it looks like the CONNECTED(...) had nothing to do with it. Thanks all for your help! On 10/3/07, Amy McIntyre [EMAIL PROTECTED] wrote: Thanks for your comments. I do not think it has anything to do with a DN hostname mismatch. It is true that your browser will give you warning if the CN in the SSL server certificate does not match the hostname you are requesting, but this doesn't affect whether you are prompted for a client certificate. To be sure, I can go to https://ip_address_of_myserver.com and it behaves the same as if I go to https://myserver.com (that is, the browser does not prompt for a client cert). It is only when I go through the switch and load balancer, that it prompts for the client cert. Thanks for the info on the file descriptor. I'll have to look more into this. On 10/3/07, Marek Marcola [EMAIL PROTECTED] wrote: Hello, I am trying to debug a problem with the browser prompting for a client certificate, and I used the following to see the details of the SSL negotiation: # openssl s_client -connect hostname:port -msg I am testing 2 different scenarios and get basically the same output for both except that the first line of the output is CONNECTED(0003) for one scenario and CONNECTED(0004) for the other scenario. What do the codes 0003 and 0004 mean? This is basically the only different I can see in the output, so I believe this is the key to my problem. To give more background, I have a server where I have configured SSL client certs to be optional. The behavior I want is that when a user makes an SSL connection via their browser, the browser should NOT prompt for a certificate unless the browser has a certificate that is in the list of Acceptable client certificate CA names that is sent by the server. This is working as expected when I go to my server's hostname directly in the browser e.g. https://myserver.com. However, there is also a switch and a load balancer in front of the server, and when I go through those components to get to the server, e.g. https://myswitch.com, then the browser prompts for a certificate, which I do not want it to do. Probably this is not request for certificate but DN host name conflict. If your server has CN=myserver.com and your load balancer switches tcp connections then browser connects to myswitch.com but in certificate you have myserver.com and browser is asking you whether it is acceptable. My guess. When I do: # openssl s_client -connect myserver.com:443 -msg the output shows CONNECTED(0004) When I do # openssl s_client -connect myswitch.com:443 -msg the output show CONNECTED(0003) This is tcp socket number/file descriptor. In first case, fd 3 is used for some reason and next fd 4 is allocated. You may look at lsof output for fd 3 usage. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
