RE: What is the difference between green and yellow address bars in browser for certificate's fields?
Hi all! > Many public CAs suggest Extended Validation for certificates > of web servers. [...] I had a talk with a specialist > of technical support of Thawte [...] He also refused > to answer how browser determines what bar to display - > green or yellow? See thawte Certification Practice Statement, Version 3.3[1], at page 96 in the PDF (section D. EV CERTIFICATE CONTENT AND PROFILE) 7. EV Certificate Policy Identification Requirements (a) EV Subscriber Certificates Each EV Certificate issued by thawte to a Subscriber will include thawte's EV OID in the certificate's certificatePolicies extension. thawtes EV OID used for this purpose is 2.16.840.1.113733.1.7.48.1 Wikipedia has a list with links to other CA EV OIDs in the page Extended_Validation_Certificate[2]. Interesting would be to have some non-Thawte certificate with 2.16.840.1.113733.1.7.48.1 - I think depending on the check implementation it could happen to appear green... > Vladimir Belov: If you say that "the SSL Web Server > certificate would have the same properties, extensions, etc, that > our Extended Validation certificates " > Clifford: Unfortunately that is information that we cannot disclose. > Vladimir Belov: Why? :) > Vladimir Belov: Is this so secret? > Clifford: That is correct. I consider this unacceptable. This is not just "Security through obscurity" [3], because the "Certification Practice Statement" in my opinion MUST NOT be secret. Interestingly, I had to use the Thawte web search function to locate the document, I think it better should be easy to find. Trust is all about believing that CPS are strictly followed -- and that they are sufficient for customers need. So they must be available I think. I'm afraid this shows how uninterested users are in trust... Regards, Steffen [1] https://www.thawte.com/assets/documents/repository/cps/Thawte_CPS_3_3.pd f [2] http://en.wikipedia.org/wiki/Extended_Validation_Certificate [3] http://en.wikipedia.org/wiki/Security_through_obscurity -- End of message. About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 17 million terminals deployed in more than 125 countries. Over 3,600 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
Hi all, > Which version of the ANSI Spec, and where did you get a copy? > > I have to rely on secondary sources and experience using > various implementations that claim conformance. Wikipedia http://en.wikipedia.org/wiki/ANSI_C is used to have a link to a recent draft (free of charge) which is known to be very close to the standard, currently it points to a plain text document at http://flash-gordon.me.uk/ansi.c.txt. oki, Steffen 4.10.3.2 The free function Synopsis #include void free(void *ptr); Description The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs. Otherwise, if the argument does not match a pointer earlier returned by the calloc , malloc , or realloc function, or if the space has been deallocated by a call to free or realloc , the behavior is undefined. Returns The free function returns no value. -- End of message. About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 17 million terminals deployed in more than 125 countries. Over 3,600 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
Hi all! > > If the library crashes on free(NULL), you're just making > > people like me do this everywhere: > > > > if (ptr != NULL) free (ptr); ok, if you have a test case "free (NULL)", agreed ;-) Seems not all platforms conform to the "free(NULL) is a no-op". I understand your example, thanks for that, but I don't think that this is the general case for "validating parameters". Actually, NULL even is a valid parameter to free! My comment was about: > > > validating parameters before operating on them I just wanted to tell, that it is not possible to validate pointer parameters in C. You might be able to invalidate a few (NULL and (-1) maybe?), but you cannot validate. So functions must rely on the validity of passed pointers. NULL could be may indicate an optional parameter: the parameter / the object can be omitted, but otherwise it must be valid, or in short, the passed object must be valid. Checking "(ptr != NULL)" IMHO is not validating parameters, but it is checking for one special case. There are many more possibilities for invalid pointers, and most cannot be checked for. Also setting ptr = NULL after the free is not safe, because other pointers to the same object may exist. All those measurements surely can limit damage - but also increase later damage. This does not mean checking for NULL is bad!! -- it means checking for NULL is no reliable "parameter verification". Especially since NULL is valid return value of malloc and argument to free, ptr == NULL does not even indicate an invalid parameter, because for example to free() it is a valid one. > Any secure programming standard would also require that you > set ptr to NULL as soon as you free it. > Re-using already freed memory pointers is a common source of > both bugs and security holes. Yes, I agree. Set it to NULL -- but still, better not rely on that. If a pointer is NULL at a point in code where it shouldn't be NULL, just adding an "if(ptr != NULL)" (for that mandatory ptr) could lead to issues later. Here, assert() might help to spot bugs in development. If the pointer might be NULL, it is a valid one, of course then no assert. Double-free looks wrong even if pointer was set to NULL and second free has no effect. oki, Steffen -- [end of message] About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 17 million terminals deployed in more than 125 countries. Over 3,600 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Custom free routine is invoked with NULL argument in openssl 1.0.1
Hi all! * Jeffrey Walton Sent: Friday, May 25, 2012 4:39 PM > On Fri, May 25, 2012 at 7:25 AM, Sudarshan Raghavan > wrote: > > Ok, I can fix the custom free to take care of this. > > But, why is this happening in openssl 1.0.1 and not in 1.0.0 or > > 0.9.8? > > I think the question to ask is why your code or library > routines are not validating parameters before operating on > them. Its a hostile world full of mis-users and adversaries - > look for any reason to deny processing (and if you can't find > a reason, begrudgingly perform the processing). I think in this case the parameter *cannot* be checked. The passed parameter is a pointer to dynamically allocated memory and a C application has not way to correctly check a pointer for being valid. It can be a valid pointer to static .text or to already freed dynamic memory, it could be a wild pointer or some other dangling one. Of course it is possible to add some checks like for non-equal to NULL or non-equal to "whatever limited list of known invalid pointers" (also pointers to functions cannot be freed etc), but I think this only missleadingly suggests that a function would be able to check its pointer arguments. I think crashing with NULL is quite good: a must-not-happen situation leads to a defined dead of SIGSEGVs, at least for platforms supporting that, typically with good aid for debuggin (like core files or halting debuggers providing a backtrace). Maybe adding an assert() before. oki, Steffen -- [end of message] About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 17 million terminals deployed in more than 125 countries. Over 3,600 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Why CVS?
> > With Git, Mercurial and other revision control systems > > available. Why is OpenSSL still suck on CVS? > > Moving a mature project off of CVS is not trivial. Also, why move at all? People can development features with let's say GIT, even in teams and concurrently, and then checking in to CVS, when using cvsexportcommit even without losing history. oki, Steffen -- end of message. About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Re: Verify intermediate certificate
* Johannes Bauer wrote on Fri, Jan 13, 2012 at 14:22 +0100: [...] > >>> Or, in other words: Let's assume I have a ultimate root > >>> (self-signed) "Root" and a branched CA "X". I would like to > >>> trust "X" and all it's children, but not "Root". Is this > >>> not possible? [yes, it is not possible "by default"] > Thank you for your clarification. I also do not really see the > point why the anchor of trust has to be self-signed. I also wondered about this time ago. I think when a user explicitely puts a sub-CA or even a non-CA certificate into the database of trusted certificates, chain verification could stop there without knowing the root-CA. Only point to require root-CA is to check if it still is valid and require it in order to be able to check it's CRL for the sub-CA being included. Personally, I still wonder why I should be stopped from trusting a sub-CA even if the root-CA revoked it when I explicitely configure it to do so, but anyway usually OS or browser vendors seem to decide for the users whom to trust ;-) > In my scenario this restriction actually makes the whole system > less secure (since it allows a superset of certificates to be > valid instead of just a tiny subset). Certify the identity to be authentic, that means that the name given in the certificate is authentic. This is like an ID card or passport. >From this it cannot be concluded whether the authentic name owner is authorized for communication (or whatever). For this, some list of allowed names is needed. This is like a guest list. Unfortunately it seems to happen from time to time to meet some projects/installations that check only whether a peer is authentic but not it authorized (like: anyone with a valid password can use the VIP entry, because no guest list check is performed). For example, in a typical webbrowser I think you cannot configure NOT to communicate with authentic badguy.malware.com; if TLS makes it absolutely sure that you really communicate with `badguy', you will get a green security symbol :-) oki, Steffen -- End of message. My personal opinion only etc. About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL_Connect call gives SSL_ERROR_WANT_READ for non blocking sockets
> Since I wait until the SSL_connect() function succeeds I
> wanted to know if there is a better approach.
Yes, there is a better approach, for example the one mentioned
in the manual:
* http://www.openssl.org/docs/ssl/SSL_connect.html
> If the underlying BIO is non-blocking, SSL_connect() will also return
> when the underlying BIO could not satisfy the needs of SSL_connect()
> to continue the handshake, indicating the problem by the return value
> -1. In this case a call to SSL_get_error() with the return value of
> SSL_connect() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
> The calling process then must repeat the call after taking appropriate
> action to satisfy the needs of SSL_connect(). The action depends on
> the underlying BIO. When using a non-blocking socket, nothing is to be
> done, but select() can be used to check for the required condition.
> When using a buffering BIO, like a BIO pair, data must be written into
> or retrieved out of the BIO before being able to continue.
So it tells you should call SSL_connect again. If you just call it again
directly, you end up calling it thousand times for nothing but wasting
resources until data arives on the socket. Thus you shall wait for data
arriving on the socket and then call SSL_connect. To wait until data
arrived, you may use select(). So you could:
while(ret == READ || ret==WRITE) {
if (ret = WANTREAD) {
select(fd+1, fd, NULL, NULL, &tv);
} else {
select(fd+1, NULL, fd, NULL, &tv);
}
ret = SSL_connect(...);
}
Needed improvements include timeout management, handling select timeout
and handling of errors.
oki,
Steffen
End of message.
--
About Ingenico: Ingenico is a leading provider of payment, transaction and
business solutions, with over 15 million terminals deployed in more than 125
countries. Over 3,000 employees worldwide support merchants, banks and service
providers to optimize and secure their electronic payments solutions, develop
their offer of services and increase their point of sales revenue.
http://www.ingenico.com/.
This message may contain confidential and/or privileged information. If you
are not the addressee or authorized to receive this for the addressee, you must
not use, copy, disclose or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you for
your cooperation.
P Please consider the environment before printing this e-mail
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Secure plaintext-derived filename [was: HMAC with RSA Key]
> > 4. Truncate the string to your desired file name length, but not so > > short that accidental collisions become likely (Example to > > keep up to 16000 file names likely different, use file names with 2 * > > log2(16000)=2*14=28 bits minimum). Where can I learn more about this formula? I think it does not work well for small number of files and I wonder why it isn't something like "log2(n)+20" or "2*log2(n)+10" or so? oki, Steffen End of message. -- About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How to recover Self signed SSL private Key Pass Phrase
> can any one please help me regarding this, like how to > retrieve the SSL pass phrase , or assign a new pass phrase > for the same private key. Add all information you remember (possible parts, used characters, length information) to a key cracking tool, run it and wait? End of message. -- About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Revocation with a renewed/rekeyed Root CA
> > - U1, U2, U3 are end-user certificates, issued by CA1 > > - U1 is revoked, and the CRL is published (lets call it CRLg1) > > The problem here is that you can't trust a CRL when its > signature key is compromised. I think that this is not the reason. If a signature key is compromised but used to revoke "itself": it can be a genuine authentic revocation (e.g. as reaction to the compromise) and it should be accepted as revocation, -- or -- it can be a forged revocation by a malicious entity made possible because of a compromise and in case of a proven compromise, permanent revocation seems very reasonable, doesn't it? oki, Steffen End of message. -- About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How to deal with new OIDs
Hi all, Hi Dominik, > in a project I maintain I have to deal with OIDs not > contained within OpenSSL. In particular, I use OpenSSL to > parse ASN1 encoded data containing OIDs (using the Macros > from asn1t.h) and do switch-case statements on the resulting > NIDs. Until now I used to patch OpenSSL (adding the OIDs to > objects.txt and running the objects.pl script to generate the > NIDs) to contain my OIDs but this approach is far from ideal. Do you need to work with OIDs and other DER for ASN.1 encoded data and are using a specific part of OpenSSL as DER encoder/decoder? In this case you might take a look to http://lionet.info/asn1c/compiler.html It is free (BSD), is exists since many years and there is a lot of documentations and examples, one deals with X.509. Just in case it helps. oki, Steffen >From the webpage: The asn1c is a free, open source compiler of ASN.1 specifications into C source code. It supports a range of ASN.1 syntaxes, including ISO/IEC/ITU ASN.1 1988, '94, '97, 2002 and later amendments. The supported sets of encoding rules are * BER: ITU-T Rec. X.690 | ISO/IEC 8825-1 (2002) (BER/DER/CER) * PER: X.691|8825-2 (2002) (PER). * XER: X.693|8825-3 (2001) (BASIC-XER/CXER). The compiler was written specifically to address security concerns while providing streaming decoding capabilities. ---[ End of Message ]--- About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:293
> http://stackoverflow.com/questions/6520676/pop3s-implementatio
> n-using-openssl-library
char bf[16] = "STLS\r\n";
if (send(c->socket, bf, sizeof(bf), 0) < 1) {
fprintf(stderr, "[%d] failed writing to auth server
socket(ssl_coneect)", getpid());
}
I don't think that you intentionally write 16 bytes?
oki,
Steffen
About Ingenico: Ingenico is a leading provider of payment, transaction and
business solutions, with over 15 million terminals deployed in more than 125
countries. Over 3,000 employees worldwide support merchants, banks and service
providers to optimize and secure their electronic payments solutions, develop
their offer of services and increase their point of sales revenue.
http://www.ingenico.com/.
This message may contain confidential and/or privileged information. If you
are not the addressee or authorized to receive this for the addressee, you must
not use, copy, disclose or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you for
your cooperation.
P Please consider the environment before printing this e-mail
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: RE: RE: Cannot encrypt text - need help
* derleader mail on Monday, May 02, 2011 8:14 PM > > But what exactly do you want to know? If you can use SSL and > > Blowfish? > > It does not appear in http://www.openssl.org/docs/apps/ciphers.html. > > > Yes the web site and the book about the OpenSSL is outdated. Does TLS spec nowadays defines a Blowfish cipher suite? > If you have to design high performance server which must be > able to process many requests from clients how are you going > to design it? Lets say something like Nagios. Could you > explain in details? I would have one or two central Nagios servers that remotely collect the data. I would consider SSL (probably in form of stunnel) and SSH. Since establishing costs most performance, the SSL or SSH tunnel should be kept. I think first I would favor SSH, because I have a Linux Nagios server and would use some u*nx for the high performance servers and would have SSH available anyway. By this, the plugins running on the Nagios server could be shell scripts (or perl or whatever). Maybe having some server reachable locally only, thus remotely via stunnel or SSH port forwarder, could offer the needed data, which could be queried by Nagios plugin scripts. Of course all of this depends on the detailed requirements. I think, often monitoring has to be maintained and extended (i.e. when the UPS failed the first time, from that on you will monitor the serial link to it and it's battery level etc), so I think it is good to have something that can quickly adopted to new requirements. To monitor load and disk usage, BTW, I do not use any cryptography, because this is non-secret data in the monitoring net (read-only SNMP is used). oki, Steffen __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: RE: Cannot encrypt text - need help
> If I decide to go with openssl and blowfish what are the > potential threats? Yes, heaps of. You might consider asking more detailed. > Is there another security mechanism that I can use with blowfish? Of course... But what exactly do you want to know? If you can use SSL and Blowfish? It does not appear in http://www.openssl.org/docs/apps/ciphers.html. -- About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Re: Cannot encrypt text - need help
* owner-openssl-us...@openssl.org > What is the purpose of the project? > > This is a open source project - I need a way to monitor a > huge number of servers - monitor CPU load, RAM load, HDD > load, installed packets and etc. Why not using http://www.nagios.org/? > The data which will gathered > will be structured in JSON format and sended to one main > server - Centos x86_64. The load will very high - every for > example 2 hours the main Centos server will make checks of > the monitored servers - this means that the monitored servers > will establish connection with the main server and exchange > JSON data maybe 200+ lines. Encrypting a few bytes with some stream cipher every two hours shouldn't be a problem for a PC server, even if it has some load, I think. > Later on it will be added support for remote patching - this > will include trasportation of installable rpm file to the > remote server - sometimes bigger files will be transported. Aren't there sophisticated existing solutions for that? To sync bigger files, "rsync -e ssh --bwlimit" comes to mind. > So I need a high performance solution that can handle many > connections with little server load. Why not using SSL, for example in form of stunnel, and keep the tunnel up all the time? Or keeping an SSH connection open, which might be easiest to use from shell scripts. SSH port tunneling might also help > 1. SSL is a good solution but is not high performance - it's > more suitable for encryption of a web page. When establishing > connection more that 100 connections are used to perform the > SSL handshake and is not suitable for big bynary data. This isn't right. I think you can safely expect that SSL/TLS is according to current knowledge close to the best possible performance without trading speed for security and it can be configured well (see stunnel with all it's options, for example). So SSL/TLS is fast (for the security it provides). > 2. Symethric encryption is more suitable because it is higth > performance and will scale very well. Yes, as used in SSL and SSH. (BTW, I think only symetric encryption is suited because asymetric does not work well for longer data) > I need a high performance optimizad solution. If you only need high performance (no security), why not using plain text TCP/IP communications (firewalled)? > What is your opinion? > What will be the best approach? Maybe have a look at Nagios and use remote monitor plug-in scripts using SSH-port-forwarded access, should be easy, safe, secure, performant, maintenable and based on tested components. oki, Steffen -- end of mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: slow https conenctions
* Matthew Fletcher, Wednesday, April 27, 2011 12:40 PM > I guess that does not 100% rule out DNS/Network stuff, as SSL > could be doing extra network lookups. > > Are there any more SSL diagnostics i can enable to try and > pinpoint the problem ? maybe checking with strace -ttt -p ... which operation takes so long? oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Combining MD5 and SHA-1 to reduce collision probability
Hi, thank you for clarification, Dave! * Dave Thompson Friday, April 22, 2011 12:34 AM: > > so among 2^n+1 different messages, at least two of them > > must have the > > same 2^n bit hash (actually half because of birthday "attack"). > > To be exact: for an n-bit or 2^n-value hash, with 2^n + 1 > messages you are certain to have a collision. Because of the > birthday paradox, with about 2^(n/2) random messages you are > *likely* to have a collision. This is just a fact of nature; > "attack" is used for actions by an intelligent adversary. Just for sake of completeness I think it could be added (for the assumed intention of the OP's question) that there is no guarantee that two different messages have two different hashes, because the first two tested messages could have the same hash (of course with very very low probability). Could it even be possible that two messages shorter than n bit accidently have the same (strong n-bit) hash? Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Combining MD5 and SHA-1 to reduce collision probability
* Luc Perthuis: > Hi all, > > I'm specially interested on finding a way to uniquely > identify rather small data chunks (less than or equal to > 128*1024 bytes in size) without using a byte per byte compare. > > Is there any theoretical proof for a "good" selection of 2 > HASH (computing the results of two different algorithms on > the same data) that would annihilate the collision risk ? If the hash is shorter than possible arbitrary input message, there will be a collision risk, because you cannot resolve 2^n possible hashes back to more than 2^n possible messages (even theoretically by using "brute force", this is impossible), so among 2^n+1 different messages, at least two of them must have the same 2^n bit hash (actually half because of birthday "attack"). BTW, what is the use case? Calculating a hash takes much more computing power than a byte-to-byte compare, so I think any hash algorithm is worser than comparing (but of course using hashes can have advantages if the data is on different places or secret). And comparing 128*1024 bytes byte-per-byte is collision free :) > Unfortunately, I'd guess that the answer could be "no", but > among the experts on this list, I hope to catch a solid > proof, not only a guess. I think since any n-bit hash guarantees a collision after at least each (!) 2^n different input messages, using a n-bit and a m-bit hash guarantees a collision after at least each 2^(n+m) different input messages. > NB: I've mentioned MD5 and SHA-1 in the subject, as they are > the most used nowadays, but if this association doesn't fit > the need whereas another does, that would be interesting anyway ;-) SHA-1 collision attack need 2^63. Similar to MD5 (I guess ~ 2^64?). SHA-256 should be much stronger, would this be sufficient for your needs? Or SHA-512? oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: BIO_do_accept() + fork() is leaking 64B?
> -Original Message- > > BIO_set_close(bio, 0) > No, I haven't tried it yet, but it seems this is what I've > been looking for- clean & neat. Is it? Wouldn't this mean that father process sooner or later runs out of file descriptors? Shouldn't the father process close(2) and the child - after finishing the connection - shutdown(2)? oki, Steffen __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How to handle "Expired" or "not yet valid" X.509 certificates - or simply is the system date wrong?
Hi, I though this was already discussed, but I cannot find pointers. When some entity verifies a certificate, finds a valid signature etc but the current date is not between "Valid From" to "Valid To", meaning the certificate seems "not yet valid" or "expired", what is recommended to do? I think, essentially, this should be application specific, but are there guide lines or common sense? In practice there could be issues with wrong sytem date / system clocks / time stamps, which could lead to bad situations, especially when users are not allowed to change the system date (for security reasons) and then failing to remotely administrate (because the peer rejects the actually valid certificate as "expired" or "not yet valid"). It cannot be assumed all entities are connected to the internet or any other external trusted time (except maybe an SSL protected one). Are there standards, recommendatations or any writings discussing such topics, in particular system date related topics? oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Let's talk about HTTPS Everywhere
* S Mathias wrote on Wed, Jan 19, 2011 at 03:29 -0800: > Ok. It's a Firefox Add-on: > https://www.eff.org/https-everywhere > 3) Can someone trust this Add-on? Is it safe to install/use? It isn't 100% safe. There always is a risk. > 4) If it's so great why isn't it more prevalent? > What's youre opinion? Or answer? :\ Against what kind of attack should it protect? Against traffic sniffing by ISPs preventing user profiling? I think for sensitive applications like online banking or so an automatic `enable SSL if accidently possible' isn't sufficient. For non-sensitve applications like editing Facebook information visible to the public it seems not to add much (assuming that Facebook correctly secures sensitive operations like loging in, yes, I know that this is unlikely :)). Personally I think in those cases it might not be worth spending the additionally needed computing power... I guess it is a similar concept like `opportuntistic encryption' (FreeS/WAN), which has advantages and disadvantages. What do you think? BTW, I dislike the name `everywhere': `HTTPS Everywhere can protect you only when you're using sites that support HTTPS and for which HTTPS Everywhere includes rules.' I would expect that if an attacker hijacks some link or performs some phishing via let's say facebook.com.malicious.net, the plugin probably does not help. oki, Steffen End of mail -- About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL/TLS with server names picked from DNS
Hi! * sandeep kiran p wrote on Wed, Aug 11, 2010 at 20:36 -0700: > Ours is an LDAP client application that fetches LDAP server names on > the fly using DNS SRV Resource Records. We then randomly pick one the > servers returned from DNS, establish an SSL/TLS connection with that > server and then perform a bind operation using user credentials (DN > and password). User credentials are protected since everything goes > encrypted between the client and server. > > Recently we discovered that such a mechanism could be vulnerable to a > DNS spoofing attack where an attacker could modify (or drop) the > server list returned by the DNS and inject his/her own malicious > directory server name. Client would then blindly establish an SSL/TLS > connection with that server and would end up handing over the user > credentials to it. Note that, as part of the SSL handshake, the > malicious serve would provide a certificate signed by the same CA that > signed a genuine server certificate. I think this is a common pitfall: the server connected to is authenticated (i.e. it really is ldap.malicious.com) but it is not checked if the peer is /authorized/ to get the credentials. It is like asking someone to show his passport, verifying if the passport is authentic, but neither checking the name written on the passwort nor checking if it is on the guest list at all... If not everyone is authorized, I think you need some definition of permissions, like an association of DN and permissions or a white list. Don't know if major public CAs offer this, but maybe you also could define a dedicated property in the certificate (but all CAs you trust must guarantee to use this properties ONLY for this case - I guess it will become at least very expensive). But maybe some hostname white list is sufficient. This list must be authentic (hardcoded, local config file or dynamic file which is cryptographically signed), so non-DNSSEC'd TXT records won't help of course. But if you do not want to communicate with everyone, why rely on PKI, maybe you just want to have a local list of the certificates of authorized peers? PKI is good to authenticate everyone, without knowing in advance, but seems you do not want this, but just want to communicate with someone known/trusted/authorized in advance. Sometimes PKI seems to me like a hammer making every problem looking like a nail, but in turn it has to advantage that a well researched crypto system is used. Also it should be noted that in case of MITM the link from LDAP client to ldap.malicious.com IS secured! Only the attacker can read the traffic, ensured cryptographically! oki, Steffen --[ end of mail ]-->8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
end users managing trust databases (was: Re: Wildcard certs?)
* Kyle Hamilton wrote on Fri, Jul 23, 2010 at 20:06 -0700: > There's a company called StartCom (http://www.startssl.com/) who will > do 2-year validity wildcard certs, upon verification of your identity > and verification that you have control of the domain for which you are > requesting certificates. One of those `we verify by plain text mail and secure by 2048 bit RSA' CAs? (Cool is the idea to send an email to mydomain.com before creating a certificate to protect against mydomain.com domain name spoofing; if the attacker spoofed DNS already, she can request a certificate and automatically get the verification mail send to the spoofed domain). > Oh, and they're included in the latest Microsoft Root > Certificate Update for Windows XP, and all later versions; Could it happen if someone removed the certificate from the lists of trusted CAs that it would be reinstalled? I just checked my WinXP workstation and I don't find it, but I cannot check after each winupdate... > Firefox recognizes them, they're part of Apple's certificate > store, and it's pretty much only Opera who doesn't recognize > them for whatever reason. Because of this, unfortunately, end users have almost no chance to correctly perform their trust management. It is not transparent what tool uses which trust database - and it is even updated automatically. But on the other hand, most users don't even know what all this is about. Even banks tell their customers, seeing some small lock icon already means `secure'... oki, Steffen ---[end of message]>8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: RPMBuild for FIPS OpenSSL
* Mark Parr wrote on Thu, Jul 08, 2010 at 13:42 -0500: > I then loaded the openssl-fips-1.2.tar.gz file into a different > directory and attempted to create a RPM install for it as well but > have hit some issues. First off, rpmbuild complained that it could > not find the openssl-0.9.8f.tar.gz file in /usr/src/packages/SOURCES. > I found and changed the version information in the .spec file to > version 0.9.8o since that tar.gz file was in the given directory. that means, you wrote a SPEC file for it? Based on the one from some openssl.src.rpm? > error: Installed (but unpackaged) file(s) > found: > /usr/lib/engines/lib4758cca.so > /usr/lib/engines/libaep.so > /usr/lib/engines/libatalla.so [...] > Can the FIPS compliant OpenSSL be built as a RPM? If so, what am I > missing to complete it properly? Not sure what you mean... Technically, of course you can include any binary data to an RPM if you want. Seems you wrote a SPEC file which does not mention those files (/usr/lib/engines/lib4758cca.so etc), so they would not be included in the RPM, althrough the srcdist installed them (probably indicating that they should be in the RPM). Of course you can simply disable this error by adding to the .SPEC file something like: # avoid "error: Installed (but unpackaged) file(s) found:" #(see http://www.rpm.org/hintskinks/unpackaged/) %define _unpackaged_files_terminate_build 0 which technically works but probably logically is wrong, or you list all those files in a `%files' section to make them go into the RPM package, maybe something like: %files %defattr(-,root,root) /usr/lib/engines /usr/lib/pkgconfig or maybe better (safer) list each file individually. Was this your question? oki, Steffen --[end of message]->8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Doubts about certificates
* Sebastián Treu wrote on Mon, Jul 05, 2010 at 10:39 -0300: > if we can use a fake DNS that resolves a name as we want and > also we can gather that certificate to be installed in the > fake-server, This fake-server would not have the secret key belonging to the public key certified in the (public) certificate. SSL/TLS handshaking verifies that each peer really has the secret key (by requesting a signature made by it). oki, Steffen --[ end of message ]--->8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: additively computing SHA hash
* Subra Aswathanarayanan wrote on Mon, Jun 07, 2010 at 20:44 -0400:
>Both of you mention that OpenSSL doesn't provide such an interface.
>May be this question is not appropriate for this forum, but do you
>know of any such simpler libraries that I might be able to use?
If it is just SHA1 you need for a particular purpose, you may even use just
some sha1.c (instead of using a big library), for example:
http://www.koders.com/c/fid17B8BC1580A40B49AE494B182AF91A73CBF62B38.aspx?s=sort
http://www.koders.com/c/fid292402EE6741EB2682D9E89AEF3A29B7B2C73F32.aspx?s=sort
the context to be (serialized and) saved is:
struct sha_ctx {
u_int32_t digest[SHA_DIGESTLEN]; /* Message digest */
u_int32_t count_l, count_h; /* 64-bit block
count */
u_int8_t block[SHA_DATASIZE]; /* SHA data
buffer */
int index;/* index into
buffer */
};
your implementation will depend on the structure, i.e. if it
changes, your application breaks. Thus using an libraries private
structure (like including private header files to see what is
inside a struct which has just a forwarder in the public header)
has the disadvantage that as soon as the library is changed, your
application may break, because it uses internal interfaces and
relies on hidden data. When you have a copy of sha1.c, it is your
structure and you have the control. For testing, you might even
use memcpy(dest, ctx, sizeof(struct sha_ctx)).
I assume by serializing such a context, your application depends
on the hardware architecture (e.g. byte order), even if
serialization takes byte order into account the implemenation may
fail (for example, if `block' has to have a specific format).
When Engines are used, for example a smart card, it might even be
impossible to serialize a context in the way you need it (I would
intuitively assume that any hardware token would prohibit such
usage to avoid potential miss-use).
oki,
Steffen
About Ingenico: Ingenico is a leading provider of payment solutions, with over
15 million terminals deployed in more than 125 countries. Its 2,850 employees
worldwide support retailers, banks and service providers to optimize and secure
their electronic payments solutions, develop their offer of services and
increase their point of sales revenue. More information on
http://www.ingenico.com/.
This message may contain confidential and/or privileged information. If you
are not the addressee or authorized to receive this for the addressee, you must
not use, copy, disclose or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you for
your cooperation.
P Please consider the environment before printing this e-mail
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: question about exponent, key length and all other RSA parameters not configurable
* Chuck Pareto wrote on Mon, May 24, 2010 at 16:12 -0700:
>Hi,
>When I run openssl rsa to display my public key info. I see this
>below. How do I convert this output to a byte array? What is this
>output? Is it ascii or base64?
it's ASCII and in the Mail potentially base64... :)
surely it is a list of hex values for the bytes (a "hex dump")
in which language? Simplest is perl, use something like:
perl -e 'my $ahex = $ARGV[0] || jn("", <>);chomp $ahex;$ahex =~
tr|0-9A-Fa-f||cd;print pack("H*", $ahex);'
and feed via STDIN and get binary via STDOUT.
Often also it can be helpful to use such a small perl script to
generate source code when someone wants to embed test keys in
source code, for example certificates to be included in unit
tests or have a small parser in the target language that takes
the output of the tool as input to ease maintenance.
I think there is a standard tool to convert binary data to C
code, but I cannot find it. Maybe `od' is a starting point for an
own construction.
oki,
Steffen
-[end of message]-->8===
About Ingenico: Ingenico is a leading provider of payment solutions, with over
15 million terminals deployed in more than 125 countries. Its 2,850 employees
worldwide support retailers, banks and service providers to optimize and secure
their electronic payments solutions, develop their offer of services and
increase their point of sales revenue. More information on
http://www.ingenico.com/.
This message may contain confidential and/or privileged information. If you
are not the addressee or authorized to receive this for the addressee, you must
not use, copy, disclose or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you for
your cooperation.
P Please consider the environment before printing this e-mail
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Is it not possible to decrypt partial AES messages?
* Christina Penn wrote on Wed, May 05, 2010 at 07:42 -0400: >Can you show me exactly how to break up my example code to make my >example work? I tried removing the EVP_DecryptFinal_ex from my >DecryptMessage function and just seeing if the first part would just >decrypt the first 7 bytes, the algorithm works on lengths with (len % blocksize) == 0, i.e. on lengths that are multiples of blocksize, for AES-128 that are 16 byte (or 32, 48...). Note that the blocksize of AES-128 is 128 bits (16 byte), but your `int blockSize=128;' is used as 128 bytes, which at least is confusing. Also, note not to use `std::string message' for encrypted binary data because it may contain binary zeros (also note malloc() can fail etc, casts are ugly and C-casts in C++ are worse, etc, SCNR :)). >but it got thrown into my catch statement. >I am really confused. (I'm also confused, because there is no `throw' anywhere...) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question regarding opening the OpenSSL source code in visual studio
* Modem Man wrote on Wed, Apr 28, 2010 at 17:49 +0200: > > Since I'm working under Windows and have Visual Studio installed, the > > easiest way to do so will be by creating a visual studio project with > > the source code > > I tried it and stopped after ~4 hours. [...] > Next, split makefile into modules with same -D and -I settings. so seems using DevStudio IDE building isn't an easy way, but maybe it is sufficient to run a custom build command to build OpenSSL - the debugger will work as long as CL.EXE was called with the needed debug switches (i.e. it is not needed to make DevStudio run the compiler, also make can do, the debugger works in both cases). Just in case it helps. oki, Steffen -- --[end of message]->8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl tarball SHA1 checksum
* Kenneth Goldman wrote on Sun, Apr 11, 2010 at 15:36 -0400: > owner-openssl-us...@openssl.org wrote on 04/11/2010 01:38:14 PM: > > * Kenneth Goldman wrote on Fri, Apr 09, 2010 at 08:12 -0400: > > > I notice that the tarballs also include a SHA1 digest. > > > What's the point? > > > > To have a check whether the FTP download was successful to > > avoid accidentally using corrupt files, a file integrity > > check with a checksum is quite common. > > Aha. So it's just a double check on ftp? It's not trying to > protect against an attacker targeting the openssl site or the > download process? (I cannot tell the intention of the checksum, because I don't know the involved processes, but I think it is wrong to take it as authenticity check). I think, to protect against malicious OpenSSL source code you have to retrieve the analyzed and approved version from the security lab you trust and appointed (ensuring authenticity by e.g. cryptographic means) and/or to verify the diff to the last checked version. Otherwise an attack to let's say the CVS server could succeed (if done well, checksum of announcement could even `proof' this malicious modification `authentic', if the attack had been done in a way remaining unnoticed by OpenSSL release process). oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl tarball SHA1 checksum
* Kenneth Goldman wrote on Fri, Apr 09, 2010 at 08:12 -0400: >I notice that the tarballs also include a SHA1 digest. What's the >point? To have a check whether the FTP download was successful to avoid accidently using corrupt files, a file integrity check with a checksum is quite common. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: PKCS#7 extract and verify certificate?
* Eisenacher, Patrick wrote on Tue, Feb 23, 2010 at 12:30 +0100: [...] > "The selection of a trust anchor is a matter of policy: it >could be the top CA in a hierarchical PKI, the CA that >issued the verifier's own certificate(s), or any other CA in >a network PKI." > > And no, I don't need a separate truststore for subordinate-CAs. > I have one truststore into which I put those certs that I > trust. I only have to build up and verify a path up to a cert > in my truststore. After all, a trust anchor is just that: an > anchor of trust. I don't need to verify further, when I trust > that entity. I think using a sub-CA as trust anchor might even seem stronger, because base-security is bound to cryptographic keys instead on some subject's string content. When relying on some subject's string content, let's say evaluating whether O=MyOrg, legally ascertained contracts with all(!) super-CA's might be required to ensure that none else never ever will also get O=MyOrg - even if in some special closed group in a country on the other side of the globe has a special sub-CA, this must never ever issue O=MyOrg. I think this comes close to requiring that all sub-CAs must be trusted. Knowing that there are sometimes lower-security-level sub-CAs for personal mail certificates or alike, this might seem weak. Writing complex string matching rules seem to be complex and thus error prone. Am I wrong? Corrections appreciated! In practice someone might not use the sub-CAs `ordinary' certificate but might want to use a `root' certificate (self-signed by the sub-CA). For the use case that only certificates by this sub-CA shall be accepted, I think it is OK to make this to be the `local root CA'. > Things get differently of course, if you do revocation > checking, in which case you always have to build up the whole > path from ee to root-ca. But I stated that before and we both > agree on that. I think this also might depend on policy. If I would buy a sub CA certificate MyOrg from ACME-CA and later have a special context where I have reject all non-MyOrg certified chains and having MyOrg as trust anchor, I might not be allowed according to the policy to give ACME-CA the theoretic possibility to revoke the MyOrg trust anchor (because it is the anchor and by definition the root of any [all] trust). Is this correct or fails it elsewhere? Also I could imagine that MyOrg is (cross-) certified by many super-CAs, maybe because it also issues web server certificates and a root CA known by default in major browsers might be desired. I would not trust any ordinary end-user CA enough that they never ever will generate a MyOrg certificate if for example a valid business company has the correct valid official name MyOrg. Also, when having multiple root-CAs as trust anchors, how to ensure that none of the root-CAs never ever certifies MyOrg for someone else... So best here probably is to use a self-signed MyOrg certificate, but I think when doing this confusing and trouble could occure when in one chain MyOrg is self-signed but in the peer chain it is not or other conditions? > > Yes, it is probably a limitation to OpenSSL that it doesn't > > really have a > > "Trust Anchor only" store, but if you take a look at most major > > implementations (US DoD, FBCA, CertiPath, SAFE, etc.) then > > they pretty much > > always use self signed "root" certs as the trust anchor. > > openssl has a truststore. It just doesn't allow to trust > subordinate-cas that I intentionally put in there to be > trusted. And that's what I consider a limitation. Yes, even if sub-CAs are locally avialable (trusted), they are not trusted. I felt this confusing. > So suppose, verisign has 2 subordinate-cas, one for securely > registered ees, and one for not so securely registered ees, > both subordinate-cas have a common verisign root-ca, and both > have the same policy identifier or none at all in their certs. I guess you cannot get a written contract (without paying heaps of money at least :)) from verisign guaranteeing that they never ever will make a third sub-CA with some property clashing with the implemented path-verification/policy algorithm. > How would I achieve my goal to only accept ees certified by the > secure registration ca? This should be a common scenario after > all. I've read a few specifications requiring that an official public CA shall be used to obtain certificates but not requiring to perform any subject content checking, which, if really someone would implement it this way, would allow anyone to obtain a certificate by this public CA. By this, he is authenticated but not neccesarily authorized, but often it seems both are not separated strongly enough (in terms of high security, i.e. as secured as the certificate itself is). oki, Steffen -- --[ end of message ]--->8=== About Ingenico: Ingenico is a leading pro
Re: Thread locking functions
* Sad Clouds wrote on Mon, Feb 15, 2010 at 14:52 +: > On Mon, 15 Feb 2010 15:19:23 +0100 > "Steffen DETTMER" wrote: > > Delegating functionality via callbacks allows arbitrary > > implementations; I would not consider this lame > > - but clean, strong, orthogonal, KISS and divide-and-conquer :) > > > > Neither ANSI-C nor ISO-C tell anything about multi-threading or > > mutex locking, so handling that transparently inside the library > > would introduce additional dependencies (e.g. to POSIX threads) > > and thus would not be portable. > > I think pretty much every Unix platform standardised on Posix > threads by now. Using locking implies that you're using > threads, and that is Pthreads API on Unix. yeah well if you have to support POSIX platforms only... how enviable! But there are others, too... :) > I still think it's library's responsibility to pick the most > efficient locking primitives for a given platform and use them > transparently, without exposing the semantics to the > application code. I think this would require OpenSSL to know all platforms and usage ways, which might not neccesarily be possible. > What happens if your application is linked to > other libraries which use OpenSSL and try to set their own > locking callbacks? The same as what happens if you application is linked to a libc that is re-targetted differently: it won't work :) > I have a feeling the locking callbacks mechanism is the > leftover from the 90s era. Even today there are embedded devices, for example. If there is no need to introduce dependencies to POSIX, why should OpenSSL do this, limiting itself? Allowing arbitrary implementation by such a way has advantages I think. In Java context someone may even call it Dependency Injection or Inversion of Control pattern (just to use a buzzword :)). oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Thread locking functions
* Sad Clouds wrote on Mon, Feb 15, 2010 at 13:18 +: > 2. Rationale for callbacks? > > Pushing some of the responsibility for locking OpenSSL internal > structures to application developers seems a bit lame. Why not get rid > of locking callbacks and have OpenSSL handle it transparently inside > the library? This promotes the idea of abstract data types and > encapsulation and avoids the whole mess of static/dynamic callbacks. (I'm just guessing - please correct me where I'm wrong). Delegating functionality via callbacks allows arbitrary implementations; I would not consider this lame - but clean, strong, orthogonal, KISS and divide-and-conquer :) Neither ANSI-C nor ISO-C tell anything about multi-threading or mutex locking, so handling that transparently inside the library would introduce additional dependencies (e.g. to POSIX threads) and thus would not be portable. I think there is no abstract way of locking. For example, mutex locking can be done using a `recursive mutex' (such as locking in Java), but others consider this wrong and never use it; or you might want to use a data type in reentrant functions and thus cannot lock at all (non-recursively); a platform may have globally valid semaphores only or a limited number of them or... So many things to consider that I doubt it could be encapsulated correctly. oki, Steffen -- --[ end of message ]--->8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Alternative Name Help
Hi! * Victor Duchovni wrote on Fri, Feb 12, 2010 at 15:03 -0500: > On Fri, Feb 12, 2010 at 08:35:09PM +0100, Steffen DETTMER wrote: > > > (So DER encoding is used, and it is allowing 128 byte long > > length fields allowing 2^1024 [a number taking four and a half > > line in xterm because 309 decimal digits long] bytes long value > > fields sufficient to enumerate every atom in the visible > > universe an unbelievable huge number of times > > - but in the end for certificates limit of 16384 [5 digit > > number] is in effect :-)) > > SSL protocol engines need sensibly sized I/O buffer size limits. > The decision to limit SSL record lengths is reasonable. 16K > is a fine choice. And yes, 5000 altName entries in a certificate > is absurd. It may be the most expedient way to overcome design > implementations in the software you are forced to use, but the > SSL protocol is not obligated to support this use-case. Of course you are right; I guess the 5000 altName-case isn't a perfect solution (but maybe some workaround, who knows), however limits close to practical order of magnitude (I mean just 10 or 100 times more than needed) can turn out too limited during protocols lifetime, I think, such as the famous 640 KB. Maybe in future some governmental approved personal X.509 certificates have to include a passport photograpy of the owner in 640x480x24 PNG format? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Alternative Name Help
* Victor Duchovni wrote on Fri, Feb 12, 2010 at 14:20 -0500: > The limit is not (only?) an X.509 limit, rather the SSL/TLS > record layer cannot carry messages larger than 2^14 bytes (plus > some overhead for compression algorithms which provably need to > be able to make some records larger in order to make most > records smaller). Given that the server certificate message in > the SSL handshake needs to fit into a single record, the > SSL/TLS protocol constrains certificates to 2^14 (16K) bytes. oki, thank you for the clarification. (So DER encoding is used, and it is allowing 128 byte long length fields allowing 2^1024 [a number taking four and a half line in xterm because 309 decimal digits long] bytes long value fields sufficient to enumerate every atom in the visible universe an unbelievable huge number of times - but in the end for certificates limit of 16384 [5 digit number] is in effect :-)) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Subject Alternative Name Help
* Victor Duchovni wrote: > The SSL/TLS record layer has a maximum record size, a > certificate probably needs to fit into one record, so if your > 500+ domains generate a certificate that is larger than ~16K > bytes, you may be out of luck. (I just ask for curiosity, not because I have any problem with that!) Does this mean that OpenSSL has a compiled-in certificate size limitation and to increase that it would be required to replace the libs on the systems needing to support bigger certificates? oki, Steffen -- --->8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Should CSR be protected?
* Patrick Patterson wrote on Sun, Feb 07, 2010 at 10:14 -0500: > > A quick question here. Should the Certificate Signing Request message be > > protected when requesting for Certificate from CA? I think, if you want to certify that a public matches subject description, of course you should authenticate both. > The first question, is "How are you protecting this channel?" - there > are several common ways. For instance, in many models, the Subscriber > logs into an interface (usually a web site) provided by the CA, which is > protected by SSL/TLS, using one or more codes provided to that If you already have a mutual trust, why would you want to create an additional certificate? I think, for renewal, strictly speaking, this might not be the best, if the keys or certs are changed due to security reasons it seems doubtfull to protect the renewal process by exactly the keys/certs to be changed. > Properly done, there is very little room for a MITM attack to succeed. > However, to further mitigate this... I think it feels a bit like pulling yourself up by your bootstraps... Often it is not possible to increase the security level by the security that is to be increased, is it? oki, Steffen -- --->8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why don't openssl RSA work for Word Document file?
> Namrata Sorte wrote: > > Ya to be more specific, I want to sign and verify Word Document > > File and using command line will be fine for now. Are you looking for something like openssl smime -sign -in ml.doc... openssl smime -encrypt -in in.doc... maybe? With RSA based certificates it uses RSA. oki, Steffen -- --->8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: can TLS be used securely or it is flawed by design not allowing to use it securely
* Kyle Hamilton wrote on Tue, Jan 19, 2010 at 16:00 -0800: > On Tue, Jan 19, 2010 at 6:19 AM, Steffen wrote: > > * Kyle Hamilton wrote on Thu, Jan 14, 2010 at 15:50 -0800: > > (assuming, that a peers identity should not change within a > > session - but as discussed later in this mail this could be > > wrong?): > > If there's a certificate DN or Issuer change (even from null to > something non-null), I agree that in many/most circumstances it's > reasonable to abort the connection. It doesn't necessarily follow, > though, that because it's the reasonable thing in most circumstances > that it's the correct thing to do in all circumstances. mmm... I do a bit hard understanding this... the tunnel is to ensure to talk with an authentic identity. Like in real life someone my tell some things only to his girl but not to the postman. I do not expect that the identity I'm connected to changes during the conversation (i.e. I would consider designs where girls pass the cell phone to the postmen as bad :-)). > (Imagine an ATM with a TLS-encrypted serial line or other link back to > the central processing house. It has its own certificate -- the > processing house doesn't want to accept connections that it can't > authenticate -- so it builds that TLS channel with mutual > authentication... but the ATM doesn't have any accounts, so its key > and certificate can't be used alone to compromise any accounts. Then, > Imagine USB "ATM cards" that could be plugged in, with an attendant > "please enter your PIN" message on the screen of the ATM that would > unlock your private key, so that the ATM could then initiate a > renegotiation as you... and the server initiates renegotiations every > 6 seconds to ensure that you're still there. Then, when you remove > your USB stick, the machine reauthenticates as itself. mmm... I would guess that in such a situation the remote side would want to know that: maybe only the USB tokens are allowed/autorized to communicate here or whatever. But I see that there might be cases where it could be used, ok. So the perfect browser might need a configuration option to accept `Identity Changes' after accepting a certificate, maybe even URL-based to avoid that banks change while performing transactions. > > OT: > > I personally would wish to be able to put a browser tab or > > better even a browser instance into some `secured' mode (for > > online banking HTTPS but not for myspace HTTPS). In this mode, > > flash would not work, no plug-ins installed and I would be > > Note: My bank's multi-factor authentication mechanism uses Flash, so > it would be necessary for each site to provide a manifest of what it > makes use of and what the maximum privileges each should have on the > user's system. However, this is a very good idea. I don't know of > any rendering engine or browser that would or could operate in this > manner (other than possibly Chrome), but at that point we're still > dealing with operating systems that can be compromised by viruses. (Flash was intended as a placeholder for any plug-in or color advertising multimedia extension) Why not keeping the pages simple and stupid. On the highly secured pages used with browser in secured mode the banking frontend could use simple HTML only, no flash and no embedded video. Wouldn't life be so much easier? Maybe someone could run a simple stable browser (not needing almost-daily-updates-with-only-2-year-support), maybe on a mobile phone which does not support any software upgrading except JTAG flashing. For the truely paranoid the adavantage here isn't that it works everywhere but that it securely works in the private basement (to make eavesdropping harder) :-) > > warned when the DN of a certificate of a web page changes (now, > > I'm warned only if CN does not match DNS name, but I would like > > to be informed: "www.xyz.com now is DN=XYZ Ltd. UK but last > > time it was DN=XYZ Inc. US" or so). Probably there are many > > This already exists and is called "Petnames", you might wish to look > for it on addons.mozilla.org. thanks, in case I'd update to Firefox 3 I might give it a try (althrough it might not be exactly what I meant). > > more nice security features that could be turned on. This would > > not prevent the twitter attack but maybe could make online > > banking attacks more expensive. > > In my case, my bank's multifactor authentication includes sending a > numeric code to my phone that I then enter into their Flash applet. > > Online banking attacks are regrettably cheap and relatively easy at > this point... MITB is the watchword nowadays. yes, MITbrowser, MITplug-in, MITtodaysUpdate... > > I think for many a `SSL secured' label on a webpage means that > > the running application (lets say a online banking web app) is > > secured. > > That's what the intrusion-detection/resistance-certification services > are for. All the lock icon means is that nobody can listen in between > you and
Re: impact of client certificates to re-negotiation attack
* Kyle Hamilton wrote on Thu, Jan 14, 2010 at 12:03 -0800: > * Steffen asked... > > ...on this level [thanks a lot again for all the clarifications: authentication levels, authentication-agnostic, URI-dependent certificates, bugfix because missed intention, MITM tricks twitter to decrypt and disclose, epoch 1 to detect renegotiation, and GnuTLS] > There's an implementation which uses OpenPGP keys/assertions, > called GnuTLS. [...stores client cert hashes...] > (and no, this doesn't count as 'design a cryptosystem'. What you're > proposing is essentially to allow the client to set its own public > key, and thus trust anchor, upon correct authentication. > public/private keypairs are first-order identities; the reason CAs > exist is because it's impossible to know who claims that any given > keypair belongs to him without external intervention, and CAs are > *supposed* to strongly bind [using their own private key] the > appropriate details of the individual who did present the public key > for certification. However, authenticating to the Server with a > username/password, and submitting a public key, is more than enough to > be able to issue a certificate related to that username.) ahh ok. This isn't common because not so easy-to-use, yes? > > Using (real) CAs could have disadvantages when it comes to > > privacy or when someone wants to use pseudonyms, I think. > > Oh dear gods yes. I've been trying to get people to see that for > years. Thank you. > > (As I think I mentioned, Wes Kussmaul is working on a project that > provides a different approach to the issue, but we're both hampered by > the lack of decent client certificate generation UIs.) Even with a UI avialable I could imagine that it could be difficult to get a wide acceptance; I think many know the term "SSL" and associate it 1:1 with "internet security". > > Difficult topic. Good to know that experts (like you) are > > working on it. > > You, since your signature says that you work for a payment > solutions provider, would not normally be one (in my eyes) to > raise the privacy concern -- but this suggests that you are in > the EU, where regulations are more strict. There are several privacy concerns in payment systems. For example, error messages may not be transmitted to protect card holder privacy (sometimes making it difficult to track down some issues), laws and requirement specs are about how to store data (like PAN of credit cards). The German electronic purse (pre-paid card) is even able to do anonymous payment transactions (requiring a card not bound to any account; such cards are rarely seen but exist). Whatever I write here is my personal opinion only and I'm not a security expert etc #include ... > > Yes, you helped me a lot, it was great lecture. Thank you very > > much that you again provided me free lessons with so many > > information!! > > You are most welcome. I think that this knowledge, above all else, > *must* be free, if people are to be able to learn how to protect > themselves and their information. > > Also, your comments here have spurred me into thinking about different > parts of the problem... for example, a user cannot be a CA, under > X.509. Ohh why not? Forbidden by rfc5280 or so? I though setting the needed basic constraint cA=TRUE would do the job? (beside that I don't know any public CA that would ever certify such a certificate because typically in the web then I would inherit the trust :-) which maybe just shows that this "chains" might be bad in general - just because I trust a CA this does not neccesarily mean I trust anyone who was able to authenticate itself to this CA). In theory, wouldn't even a self-signed user certificate be possible (e.g. when the server maintains a user-password-certhash data base), like you mentioned in GnuTLS (unless I missunderstood)? A self-signed-only "PKI"? > However, there is a different certificate profile which allows > users to issue certificates based on their own credentials, called the > "proxy certificate profile" (defined in RFC 3820 -- which I wish they > hadn't numbered it as, since it's so easy to lysdexiate that to RFC > 3280 -- the predecessor to the current PKIX, RFC5280.) It might be > useful to issue a user a certificate, and then allow authentication > using proxy certificates issued by that user's certificate, thus > reducing the number of times the private key is actually used -- > allowing it to be stored offline, for example, while proxy > certificates issued by it are online and used. ohh yes, and my USB class 3/4 smart card reader's display could display the proxyPolicy in an appropriate (for me verifyable) form, I could decide to enter my PIN or to cancel. I could generate a 1yr valid myspace cert stored on my laptop and a 10 minutes valid one for my banking account or even limited to a single transaction (including amount and destination account name in the proxyPolicy to allow me to verify on a trusted class 3/4 device). co
Re: can TLS be used securely or it is flawed by design not allowing to use it securely
* Kyle Hamilton wrote on Thu, Jan 14, 2010 at 15:50 -0800: > On Wed, Jan 13, 2010 at 5:58 AM, Steffen DETTMER wrote: > >> There is currently no way for even an ideal TLS implementation to > >> detect this issue. > >[...] > >> Yes. Please see SSL_CTX_set_info_callback(3ssl). > > > > hum, now I'm confused, I think your last both answers contradict > > each other... > > If an application can use e.g. SSL_CTX_set_info_callback to > > reliably avoid this, I have to read more on what the IETF is working > > on. If there are webservers `trusting' peers without certificates > > (allowing pre-injection) what should stop people to ignore > > whatever extension as well... > > What SSL_CTX_set_info_callback() does is tell you *when* a > renegotiation occurs. It doesn't tell you what happened before. (assuming, that a peers identity should not change within a session - but as discussed later in this mail this could be wrong?): In the implementation of this callback, shouldn't the HTTP server in first call store the peer identity (maybe the DN value of the certificate) and abort when in a second or subsequent call suddenly another value of DN is found within the same HTTP session? Does the standard require to allow / to support chaning a DN during one TLS session? (of course, most HTTPS services don't use client certificates, so it won't help in practice) > >> > Someone could expect whenever a browers window or `tab' is > >> > operating in some extended validation mode. > > As I think I mentioned, nobody ever actually mapped out the precise > semantics of how the green bar is supposed to work. That is EV's > biggest Achilles's Heel... nobody knows what it means, the same way > nobody knew what the lock meant. I think, most people take security in a very pragmatic way. It should not cost additional efforts, but the investable efforts effectively limit the reachable security. OT: I personally would wish to be able to put a browser tab or better even a browser instance into some `secured' mode (for online banking HTTPS but not for myspace HTTPS). In this mode, flash would not work, no plug-ins installed and I would be warned when the DN of a certificate of a web page changes (now, I'm warned only if CN does not match DNS name, but I would like to be informed: "www.xyz.com now is DN=XYZ Ltd. UK but last time it was DN=XYZ Inc. US" or so). Probably there are many more nice security features that could be turned on. This would not prevent the twitter attack but maybe could make online banking attacks more expensive. With firefox, this is possible using different profiles with MOZ_NO_REMOTE but this breaks other things (today, systems seem to rely on a single running browser instance). or something like `ssh -X safeu...@localhost firefox' :) Ohh, and this would catch passwords `system modal' just like ssh-add can do. It is too bad when half of the password reaches some online chat tool just because the session manager opens tabs that were open at the point of a previous crash, giving them focus for a short time... I really really dislike firefox asking for master password while continuing in the background with optional focus change... sorry all of this is off-topic. > You cannot call an application that uses SSL/TLS "secure" any more > than you can call a network that has a firewall "secure". yes, this is very true, but I'm afraid many people assume that this `any more' is quite a lot. For example, nowadays simple packet filters alone are called firewalls (some years ago, packet filters were just a less important small layer, mostly set up because it costs almost nothing, but security was applied by a combination of proxies understanding their protocol and filtering based on its content, for example with virus-checking, and TCP wrappers etc). I think for many a `SSL secured' label on a webpage means that the running application (lets say a online banking web app) is secured. > > I think this is a server (configuration) bug but no TLS bug. > > How can someone assume it would be safe for preinjection when > > accepting anonymous connections? > > ...because they didn't realize that the prior session isn't > cryptographically bound to the new session, it's a complete wiping of > the slate. It is certainly an application-design issue (defense in > depth is not just a buzzword), but it's also a TLS protocol issue as > one of the guarantees that the protocol attempted to provide was > violated. Isn't TLS requiring to use client certificates to be able to guarantee that the client remains the same? If TLS is not using client certificates, doe
Re: impact of client certificates to re-negotiation attack
* aerow...@gmail.com wrote on Tue, Jan 12, 2010 at 12:29 -0800: > On Tue, Jan 12, 2010 at 3:12 AM, Steffen DETTMER > The problem is this: > > The attacker makes a connection to a TLS-enabled server, > sending no certificate. It sends a command that, for whatever > reason, needs additional privilege (in Apache's case, Directory > and Location clauses can require additional security above what > the default VirtualHost configuration negotiates). Then, it > just starts proxying packets between the client and the server. Yeah, strange idea that. I read that it is common to do so, but I wonder why such a feature was implemented into Apache... Did this renegiotation-to-increase-security-retroactively idea ever pass any security approval? A pitty that such an attack exists, but maybe this just prooves `never design a crypto system' - sometimes security issues are really surprising :) > One way to deal with this would be to enforce that all access > to resources on the same webserver require the same "security > cloak" -- that is, have the server demand a certificate during > the initial negotiation, so that *all* data that comes in is > authenticated as being from that identity. Yes, isn't this how TLS is intended to be used and the `add a certificate based on a directory' just some hack because the user interfaces are as they are (and that are passwords and BasicAuth when it comes to HTTP/HTTPS)? > >I thought this data injection attack fails when client > >certificates would be used correctly. > > It does, in the event that the server configuration does not allow for > non-client-certificated connections in any manner, in any way, for any > purpose. THAT is "when client certificates are used correctly". [...] > If you get rid of the 'allow non-authenticated SSL clients' > part of the policy on that server, you do away with the > problem. [...] > In fact, if this [client-] certificate is presented during the initial > negotiation, it is impossible to perform this MITM attack. ok. Thank you for clarifying that. So as you wrote in the other mail, it is the `common practice' that lead to the problem. The fix IETF is preparing maybe is less a bugfix than a new feature - protecting a bit more, even if authentication is used wrongly. > In Twitter's case, they don't require certificate > authentication. This means that they will never be able to > prevent this attack without disabling renegotiation until the > Secure Renegotiation Indicator draft standard is implemented on > both the servers and the clients. > > And yes: the problem is caused by TLS misuse, but the reason > for the misuse isn't on the server side. Yes, the MITM was never able to decrypt the password, but fooled the server to do so and to publish the result. Well... strictly speaking I think the bug is that the result (the password) was published, which I think is a server but not a TLS bug (which just happend because no one had the idea for this exploit in the past). Since summary there are many aspects that work hand-in-hand: TLS does not differentiate negiotation and subsequent re-negiotations, HTTP `assumes' always talking to the same peer and replayable passwords or clear text password as with BasicAuth, best probably is to improve TLS AND stop using BasicAuth in favor of Digest Authentication AND make a dedicated login request/response at the begin of each connection in the hope that all together increase security best :) > The point I wanted to make in that last paragraph is: the users > can't figure out how to generate keys, much less submit > requests to CAs. Maybe something simpler than CAs could be used. Now server store a password for each account, why shouldn't they be able to store a hash/signature for each account? For example, browser creates a self-signed certificate (some simple UI to fill out DN only), server receives it and stores this sig like a password? Or does this count as `design a cryptosystem' already? Also server could sent back signed cert, signed in a way that server recognized but without any trust for anyone else, like a private CA (it would not even be needed to publish its certificate, if any :))? Using (real) CAs could have disadvantages when it comes to privacy or when someone wants to use pseudonyms, I think. Difficult topic. Good to know that experts (like you) are working on it. > This reduces the provisioning of client certificates, and thus > reduces the market. What's needed is a useful mechanism and > interface for managing these things, and nobody's created that > yet. But outside SSL/TLS such things exist... Maybe in TLS world it is so uncommon because public CAs and some X.500-style `global directory ideas' are so common? > I hope I've helped you
Re: can TLS be used securely or it is flawed by design not allowing to use it securely
Hi, thank you very much for all your explanation and to give me one more free training :) * Kyle Hamilton wrote on Tue, Jan 12, 2010 at 13:33 -0800: > > Isn't it a bug in the application when it does not allow me (its > > user) to configure it? As far as I know there is no way to tell > > Firefox i.e. not to accept 40 bit. > > about:config, search for 'ssl' and 'tls'. By default, Firefox > 3.0+ disable 40- and 56-bit ciphers, and I know that either > Firefox 3.0 or 3.5 disabled SSLv2 by default. SSLv3 and TLSv1 > do not use those ciphers. Ohh great, thanks for this information. I checked that also my Firefox 3 and Firefox 2 has 40 and 56 bit ciphers disabled and have `security.enable_ssl2 = false'. > > Is it possible for an application to use an ideal TLS > > implementation in a way to at least detect this? > > There is currently no way for even an ideal TLS implementation to > detect this issue. This is why the IETF is working on the Secure > Renegotiation Indication TLS extension, which is close to finally > being released. > > > Like having some OpenSSL callback be called reliably on (right > > after?) each renegiotation - where a webserver could force to > > shutdown the connection if the new parameters are not acceptable? > > Yes. Please see SSL_CTX_set_info_callback(3ssl). hum, now I'm confused, I think your last both answers contradict each other... If an application can use e.g. SSL_CTX_set_info_callback to reliably avoid this, I have to read more on what the IETF is working on. If there are webservers `trusting' peers without certificates (allowing pre-injection) what should stop people to ignore whatever extension as well... (well, of course in case of the renegiotation attack the main point probably is just that no one had this nice idea before :-)) > > Someone could expect whenever a browers window or `tab' is > > operating in some extended validation mode. > > Personal opinion here: EV was what Verisign *used* to require and > provide, back in 1995 when they were the first and only CA that > Netscape included in Navigator betas. > > The problem is that SSL and TLS are *far* too useful and general to > require the services of a public, commercial CA. I could imagine that the hyped success of SSL/TLS lead to weaknesses, because today someone can often hear `we are based on SSL/TLS and thus are secure'. Also interesting is when specifications require minimum RSA key lengths but don't tell anything about certification policies (requirements to CSPs) or require AES256 but no certificates (DH)... Which, BTW, in case of an MITM has the funny effect that it is cryptographically ensured that only the attacker can decrypt the traffic lol > > If a server uses TLS to authenticate a client, a client > > certificate is needed. If the server delegates the authentication > > and authorisation both to TLS (which means, that such a server or > > HTTPS server port could not be used without a valid client > > certificate), as far as I understood no renegiotation attack > > would be possible. > > This is correct *only* if mutual authentication is done on the initial > negotiation. Otherwise, the server accepts an anonymous connection, > receives anonymous bytes that translate into a request for a resource > that's protected, sends a renegotiation request to the client, the > client provides its certificate, and the anonymously-injected data -- > in the case of Twitter, a prefix of an entire header list -- is > processed as though it's under the security cloak of the client. I think this is a server (configuration) bug but no TLS bug. How can someone assume it would be safe for preinjection when accepting anonymous connections? It's also strange that SSL + BasicAuth seems to be so common. For many web services, users register and receive some confirmation mail with a password or alike. Why isn't it standard practice that users get a client certificate? Of course, this makes it difficult to use internet caffee, hotel or airport computers to login, but for those who use the password manager function anyway there should be not a big difference... It would not even be needed to buy at some CA certificate or reasonable authenticate when considering such a special purpose (i.e. when the site trust email which is used now, why shouldn't it trust certificates, too?). But as far as I know Browsers have no simple-to-use CSR generation, transferring CSR and importing CRT is more complicated than reading a password mail -- but I think this is nothing TLS can be blamed for. > > ...IPSec... > > If you configure an IPsec stack to allow anonymous clients, you > can't trust them. What you can do is trust the security > properties of other actions performed *within* those tunnels, > since they have different characteristics. Yes, but when it comes to webservers, anonymous clients are trusted... > > So with TLS, why do webservers assume the tunnel (layer) is > > secure and authenticated if they received a
impact of client certificates to re-negotiation attack (was: Re: Re-negotiation handshake failed: Not accepted by client!?)
Hi, thank you too for the detailed explanation. But the impact on the client certificates (and its correct validation etc) is not clear to me (so I ask inline in the second half of this mail). * Kyle Hamilton wrote on Mon, Jan 11, 2010 at 14:28 -0800: > The most succinct answer is this: the server and client > cryptographically only verify the session that they renegotiate > within at the time of initial negotiation, and never verify > that they're the same two parties that the session was between > at the time of renegotiation. [...] > The worst thing about this attack is that it provides no means > for either the client or server to detect it. As I understood, TLS implementations are not responsible to authorize a peer, just to cryptographically ensure that the identification of it is authentic. This is the same question I asked in my other reply to David's mail: Is it by design impossible to make an application using (optionally a future version of) OpenSSL to verify that e.g. the `Subject' of the peer's certificate remains constant (and authorized for the requested service)? > The client will receive the server's correct certificate, the > same way it expects to. The server will receive either the > client's correct certificate or no certificate (as the client > decides) the same way it expects to. There is no way to > identify this attack at the TLS protocol level. But how can this be, wouldn't the TLS protocol level need to see and verify the client certificate? On renegiotation, no callbacks with the new subject are possible to check if this client certificate (authenticated by TLS implementation) is authorized? I thought this data injection attack fails when client certificates would be used correctly. Does it fail or is it possible? But then an attacker needs a valid client certificate, right? But then in turn, by definition, a user presenting a valid client certificate (and who is authorized) is not an attacker but a valid user, isn't she? (alternatively, when it relies on the server not requiring client certificates I think it would not be an TLS design flaw but a missuse: if the client is not authenticated it means the server talks to anyone. If the server talks to anyone, anyone can send [inject] data. In this case I think it would not be a TLS design flaw but a missuse, caused by lazyness and that Twitter registration sends a password by mail or some confirmation link or whatever, but not a generated client certificate [with key]). oki, Steffen -- --[end of message]->8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
can TLS be used securely or it is flawed by design not allowing to use it securely (was: Re: Re-negotiation handshake failed: Not accepted by client!?)
Hi, thank you for your detailed explanations. The main thing I still not understood is whether TLS by design enforces the `bad behavior', meaning TLS cannot be used securely at all by anyone, - or - if TLS just does not enforce to use is securely, meaning that TLS relies on application code implementing and using it correctly and reasonable. I moved this topic up to have this question first (or almost first, following right after this paragraph) in the hope to get an answer to it; the rest of this mail unfortunately got so long that it cannot be read because probably it's a waste of time :( [move up from the end] * David Schwartz wrote on Mon, Jan 11, 2010 at 09:06 -0800: > > If this would be true, this means the information firefox shows > > up when clicking the lock icon does not tell anything about the > > data I will sent; at most it can tell about the past, how the > > page was loaded, but not reliable, because maybe it changed for > > the last part of the page. > > > > Where is my mistaking in thinking? > > Correct, and to the extent TLS permits a renegotiation to > reduce the security parameters without confirming the intention > to reduce those parameters at the current level, TLS is broken. Is TLS broken or is it just used in an unreasonable way? With OpenSSL, for example, I could configure to accept only SHA1 and 3DES (or stronger) and I would be safe to renegotiate to 40 bit something. Isn't it a bug in the application when it does not allow me (its user) to configure it? As far as I know there is no way to tell Firefox i.e. not to accept 40 bit. > That is, if the two ends negotiate 1,024-bit RSA and 256-bit > AES, then an attacker should not be able to renegotiate a lower > (or different) security within that connection without having > to break either 1,024-bit RSA, 256-bit AES, or one of the hard > algorithms inside TLS itself (such as SHA1). TLS permitted an > attacker to do this, and so was deemed broken. Is it possible for an application to use an ideal TLS implementation in a way to at least detect this? Like having some OpenSSL callback be called reliably on (right after?) each renegiotation - where a webserver could force to shutdown the connection if the new parameters are not acceptable? [original start of mail] * David Schwartz wrote on Mon, Jan 11, 2010 at 09:06 -0800: > > I think since TLS should be considered a layer, its payload > > should not make any assumptions to it (or vice versa). But in the > > moment some application `looks to the TLS state' and tries to > > associate this information to some data in some buffer, I think > > it makes a mistake. > > Well then TLS is basically useless. A secure connection whose > properties I cannot trust is not particularly useful. If I > receive "foo" over the connection and cannot ever know where > the middle "o" came from, what can I do with the "foo"? Anser > -- nothing. I think `trust' is not an absolute but a relative thing. Someone may trust rapidSSL certified 40 bit key connections sufficient to login into myspace via her own Wifi network, but not at all sufficient for online banking. Someone could expect whenever a browers window or `tab' is operating in some extended validation mode. If a server uses TLS to authenticate a client, a client certificate is needed. If the server delegates the authentication and authorisation both to TLS (which means, that such a server or HTTPS server port could not be used without a valid client certificate), as far as I understood no renegiotation attack would be possible. Did I understand correctly (or could client-certificate-based authentication be attacked as well)? As far as I understood the renegiotation attack bases on the fact that the server does not TLS-authenticate the client but relies on the assumption that it will talk to the same client during the whole connection / HTTP session. (I assume that the server is able to detect when a client certificate changes within renegiotation, if a client certificate change is possible at all - and is able to refuse that. So if a server does not perform client authenticate [using client certificates as TLS offers] the server cannot know the the middle "o" came from.). I think with TLS-authentication this type or renegiotation attack won't work or would at least be detectable because the client certificates Subject/CN or key changes. Is this correct? > > When using HTTP over IPSec, I think no one ever had the idea to > > open or block URLs based on the currently used IPSec > > certificate... > > I'm not sure I get the point of your analogy. ohh sorry. I hope I wasn't too confused. Or I'm just wrong. Unfortunately I need a longer explanation trying to tell what I mean: Similar, as I understood, the idea to the requirement for a client certificate on an existing connection when the higher layer protocol or higher application level demands that, for example, when HTTP browsing a specific sub directory. As I understand it,
Re: Re-negotiation handshake failed: Not accepted by client!?
Hi all! I miss something around the Re-negotiation flaw and fail to understand why it is a flaw in TLS. I hope I miss just a small piece. Could anyone please enlight me? * Kyle Hamilton wrote on Thu, Jan 07, 2010 at 16:22 -0800: > It is also, though, undeniably a flaw in the TLS specification > that's amplified by the clients of the libraries that implement > it -- because the clients don't understand the concept of > "security veil", the TLS implementations tend to provide a raw > stream of bytes (akin to a read()/write() pair) without the > application necessarily being aware of the change. Could it be considered that a miss-assumption about SSL/TLS capabilities caused this situation? I think since TLS should be considered a layer, its payload should not make any assumptions to it (or vice versa). But in the moment some application `looks to the TLS state' and tries to associate this information to some data in some buffer, I think it makes a mistake. When using HTTP over IPSec, I think no one ever had the idea to open or block URLs based on the currently used IPSec certificate... Am I wrong when I think that those level-mixing causes the trouble? If a user (by browsers default configuration) first accepts some sillyCA or www.malicious.com but then later does not accept it any longer and expects the trust that initially was given to be taken back in retroperspective and finds this failing and unsafe (impossible), is this really a TLS weakness? It seems it is, so what do I miss / where is my mistake in thinking? I also wondered a lot about the Extended Validation attack from last year; I had assumed that in `EV mode' a browsers tab is completely isolated against all others and second no other connectivity is possible as with the locked EV parameters, but as it turned out this is not the case. Everything can change but the green indicator remains. Strange... Now I ask myself what happens if I connect via HTTPS and read the crypto information as displayed by my browser and decide to accept it - but after a renegiotation different algorithms are used. As far as I understand, I would get absolutely no notice about that. I could find myself suddenly using a 40 bit export grade or even a NULL chipher to a different peer (key) without any notice! If I understand correctly, even if I re-verify the contents of the browsers security information pane right before pressing a SUBMIT button, even then the data could be transferred with different parameters if a re-negotiation happens at the `right' time! If this would be true, this means the information firefox shows up when clicking the lock icon does not tell anything about the data I will sent; at most it can tell about the past, how the page was loaded, but not reliable, because maybe it changed for the last part of the page. Where is my mistaking in thinking? oki, Steffen -- --[end of message]->8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Signing .p10 certificate signing requests
* Dr. Stephen Henson wrote on Tue, Jan 05, 2010 at 20:26 +0100: > Trying both types to see which (if any) worked would be one > strategy to handle this automatically or seeing if the initial > SEQUENCE header looked like it covered the whole file. There > would be exceptions to both cases though. Could a bad guy try to fool something here? Like having to different CSRs inside hoping some CA will do some mistake (authenticate first, sign second or so)? oki, Steffen -- --[ end of message ]--->8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Huh?
* Kyle Hamilton wrote on Tue, Nov 24, 2009 at 13:10 -0800: > [startssl.com] from the CA policy http://www.startssl.com/policy.pdf: > > Fully qualified domain names, typically .www.domain.com. or > > .domain.com. are validated by sending an electronic mail message > > with a verification code to one of the following administrative > > electronic mail accounts: [...] Thus security IMHO cannot be significantly stronger than plain text email, > Oh, and they're free. And trusted by everyone except Opera. so I don't trust a certificate issued by such a policy; could be any web mail hacker who obtained it. I guess they are trusted by everyone /who does not care/. SCNR. oki, Steffen --[end of mail]>8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify fails if two certs with same subject are in the trustedCA lookup file
* Arno Garrels wrote on Sun, Oct 11, 2009 at 16:10 +0200: > > > Why are issuers looked up by subject at all? > > > > > > > Because that's what the standards (X.509, RFC3280 et al) require. > > Ah ok, but shouldn't name duplicates be taken into account when > issuers are looked up, even though that might result in worse > performance? I guess having duplicated Distinguished Names is wrong. oki, Steffen --[ end of message ]--->8=== __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
(OT) just kidding. * Michael S. Zick wrote on Thu, Oct 01, 2009 at 16:44 -0500: > Everbody in the same room should be sufficiently security qualified > to see anything typed within that room. cheating pupils in school exams probably won't agree, neither will people who are writing love letter SMS in the subway. > In some installations, the red lights on the walls and ceilings flash > and the screens are all blanked if someone with less than a certain > minimum security qualification level is allowed entry. > And if that unqualified person unblanks a screen and types ps > -f : simple, shoot them. Isn't it safer to make `ps -f' have no effect even in this case? Or in general, if some big treat or risk can be reduced a lot for a cheap prive, why not simply do it... Saves ammo. :-) > (I was one of the guys that carried the gun in the room for years.) I assume those rooms had no windows. Wasn't the gun smoke an issue after shooting someone? So not using "cat" also is not only healthier for the typing guy but also for the others in the room - second hand smoke is a real killer! SCNR :-) oki, Steffen About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to get rid of "do you want to sign the cert" user request when signing a CSR?
(OT) * Dave Thompson wrote on Thu, Sep 24, 2009 at 19:23 -0400: > But 'ca' by default, and thus it appears to me CA.pl > always, also prompt for the CA key passphrase (unless > insecurely clear), and you're not complaining about that. I think it depends where it is stored if no passphrase is insecure. I think it could be even more insecure to have an "autosigner" that blindly signed any malicious incoming CSRs without giving the security officer any chance to say NO... ;) SCNR. oki, Steffen --[ end of message ]--->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: verify client certificate at a later point
* Victor Duchovni wrote on Wed, Sep 23, 2009 at 16:18 -0400: > On Wed, Sep 23, 2009 at 10:04:48PM +0200, Michael Prinzinger wrote: > > > I have a somewhat curious setting (without CAs) about [...] > > > > > //check certificate > > This only verifies the server's *trust chain*, but not its > identity. When there is no CA, what would be the trust anchor? If, as in X.509, a hierachy with a trust anchor is used for authentication, why calling it `completely decentralized''? oki, Steffen About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: The need for SNI ssl apache vhosts,
* Nigel Sollars wrote on Mon, Sep 14, 2009 at 19:06 +0200: > At the company we have an online store and we need to replicate it for > different locales/languages. After reading some information on the net > it seems that the RFC spec is good but the implementation ( at the time > of the writing was so so ).. what is with different ports to listen on? Issues with poor firewalls? oki, Steffen --[ end of message ]--->8=== __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
No shortcuts (was: Re: Is openssl crypto library thread-safe?)
(OT) * Mark wrote on Thu, Sep 10, 2009 at 15:54 +0100: > > No offense, but that's what the mailing list is for. > > Granted, a search might have yielded the answer as well... > > but if anything, the question should make you feel good > > because it's one mess you won't be cleaning up. > > No offense, but I disagree. This list is for questions > specific to OpenSSL programming, not for questions like "should > I do what the documentation says". Asking such a question > shows a fundamental misunderstanding on correct programming > techniques. Unfortunately this is all too common IME. Yes, since this came up again I cannot resist to tell that I really liked your statement about bad results when trying to go shortcuts and that it is not worth it. Very true. Also for designs (like trying to optimise or simplify patterns). ...what a waste when (after hours of debugging some race condition) suddenly finding some _lock() function just consisting of "/* TODO */" but no code... oki, Steffen --[ end of message ]--->8=== __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: MAC address binding to the certificate
* Anoop C wrote on Wed, Sep 09, 2009 at 18:02 +0530: >Thanks for the quick response. > I totally agree on your point. Our associates often used to try others > certificate .So I want to remove that threat also by incorporating MAC > address also into the certificates apart from the existing set up. Typically, SSL/TLS security is bound to the secrecy of a private key (secret key), not to the secrecy of a MAC address (which may be easy to disclose by looking to some label or sticker). A stolen certificate cannot be used (in a reasonable cryptosystem, such as SSL/TLS) without having the private (secret) key. Don't know what EAP-TLS is doing, but SSL/TLS usually work on top of TCP and TCP does not know anything MAC. You may even have PPP with TCP but without any MAC addresses. oki, Steffen --[ end of message ]-->8=== __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify certificate using subordinate ca
* Dr. Stephen Henson wrote on Wed, Sep 02, 2009 at 15:08 +0200: > Including a public key certificate in no way risks the > integrity of its private key as several others have said in > this thread. I think this theoretically opens the possibility to brute-force the private key. I think that Brute-forcing a private key without knowing the public key would be more difficult and problematic, because some network connection, smart card access or alike would be needed to test whether a guessed key is correct or not. When knowing the public key this can be determined quickly. Otherwise, tracks on networks could be left, smartcards fail counters may exeede or alike. Waiting for smartcards to compute RSA or networks to reply also should be much slower (limiting the number of key tests to a few per minute). Is this theoretically true (althrough far from practical effects)? (of course, it is considered hard to brute-force a reasonable private key, such as 1024 bit RSA.) oki, Steffen --[ end of message ]--->8=== __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify certificate using subordinate ca
* Serge Fonville wrote on Wed, Sep 02, 2009 at 13:00 +0200: > The chain always includes all CAs and certificates. I've done some > googling, and it shows that you can trust 'just' the intermediate CA > without trusting the root CA, altough this kinda obsoletes the purpose > of the root CA. [...] > > On Wed, Sep 2, 2009, Yin, Ben 1. wrote: > >> OK, regarding the CA deploy, such as, we have a one root > >> ca and 1000 sub ca signed by root ca. and each sub ca > >> used as ca by 1000 terminals.so the total network size > >> is 1000*1000. I also know people who would like to have such a setup but as far as I know this is not possible with OpenSSL. But maybe there is an indirect possiblity. Could someone please comment on that, telling if what I write below is true or an error in reasoning? I think, a sub CA can easily create a root CA certificate; it just needs to self-sign a certificate with subject == issuer (itself). If used in a mixed environment, the client cannot not send the certification chain (because the client cannot know whether the server is configured to trust root CA and thus needs the `real chain' or to trust the subCA-2-as-root and thus needs the `short chain'), but as far as I know this is not required as long as the servers have all (CA and sub CA) certificates avialable. If used in networks that trust the sub CA only and if the client `knows' that (because it belongs to that group), the client can send the `short chain'. Technically this is simply a root CA, but organisational it is not. It should be possible for someone who has both sub CA certificates (the one issued by root CA, the other the self-signed issued by sub CA 2 itself) to check whether the self-signed is authentic (it is authentic in case both certificates certify the same key). This could be important for parties that load `self signed sub CA certificates' to the 1000 terminals, for instance. Can anyone confirm that this could work or correct it, please? I see reasons for installing sub CA as highest trust anchor. First, as you mentioned, to limit damage in case of compromise. Someone here (Serge Fonville) asked how such a compromise could happen. Of course it should not happen, but in case the damage should be as low as possible. Possibilities to compromise as CA are not limited to brute-force a 2048 bit RSA key; it could be that security officiers are extorted or bribed, it could be, that the CA software is trojaned. It could be, that a big digger lorry or excavator drives straight to the secured environment, grabbing the safe with a small cran to a offroad monster jeep and escape through ways where police cannot follow. And so many other impossiblities that must not happen. But who knows. In case of the impossible happening, it is better to limit damage than not to limit it. It can be important that the treat decreased by the decreased possible damage, so it can be expected that the attack is less attractive, which could be interpreted as to indirectly increase security. Other reasons to want a sub CA could be to ease what certificates are accepted by introducing sub CAs dedicated to special purposes. Lets assume you have a root CA and a sub CA signing user certificates for use with S/MIME email, where user usally have their private keys on hard disk and a second sub CA signing special network certificates where the private keys are stored on hardware security modules (smart cards or so) exclusively. Obviously the practical security level differs a lot. Althrough the root CA of course can be trusted, here the first sub CAs signed certificates would not, because of lower policy. Of course the certificate issuer information can be checked, but isn't it more straightforward to bind the "I want to accept from subCA 2 ONYL" to the key of subCA 2, so taking subCA 2 as root certificate instead of trusting the root CA? oki, Steffen --[ end of message ]--->8=== __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Diffie-Hellman key exchange : Preventing MITM attack
* Victor Duchovni wrote on Fri, Aug 28, 2009 at 13:39 -0400: > The OP is not using fixed DH keys. He is proposing to use ADH key > exchange. This gives confidentiality, but NOT authentication. Yes, and confidentiality without authentication usually doesn't help much. In case of MITM, the confidentiality ensures that no one except the attacker (i.e. not even the intended receiver) can read the traffic... oki, Steffen --[ end of message ]--->8=== __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: WSAEWOULDBLOCK versus WSAECONNREFUSED
* David Schwartz wrote on Sun, Aug 23, 2009 at 15:40 -0700: > > My question is why _using the same code_ Windows is returning > > WSAEWOULDBLOCK instead of WSAECONNREFUSED when my server is down? > > while UNIX correctly returns ECONNREFUSED... > > Because Windows cannot tell whether your server is down or > [...] Nice summary and explanation, thank you. > Because Windows servers do not behave correctly, I think this suggests that replying a connect request with `tcp connection refused' would be wrong TCP server behavior, but as I understand, it is correct what Windows is doing: man listen(2) int listen(int s, int backlog); [...] The backlog parameter defines the maximum length the queue of pending connections may grow to. If a connection request arrives with the queue full the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may be ignored so that retries succeed. So unfortunately portable code cannot detect whether remote side has no listener (i.e. cannot detect whether the error is permanent or temporary). Personally I think this is itself is correct, because of course noone can tell that ever for sure (as David's server restart example shows), but customers keep requesting it and often code relies on that and behaves strangely. Steffen End of message. -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to create a non exportable private key certificate using openssl
* Michael S. Zick wrote on Wed, Jul 15, 2009 at 07:38 -0500: > You can approximate that by grabbing the processor's silicon > serial number plus grab the USB stick's silicon serial number > plus a user input (partial) passphrase. I assume a good virtualisation (maybe some patched VMWare or alike) allows to easily bypass this. Also, the OP wrote: `what if the agent takes the network card out and plug into his home PC' so here we need to raise the question if the agent takes out the CPU and plug into his home PC. > I.E: The files can't be copied to a different USB device (and still work); > The USB device must be installed on the same computer; > The user must provide the "secret" part of the passphrase. I don't have information how this is implemented, but I doubt that it cannot be attacked by virtualization and debuggers... (in other words, I'm afraid that this and several other proposals are `security through obscurity' only). oki, Steffen --[ end of message ]-->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to create a non exportable private key certificate using openssl
* tito wrote on Wed, Jul 15, 2009 at 09:19 +0530: > Now the threat is, If an agent export the certificate he > acquired in a USB or in someother way and goes to his home pc > or somewhere else and he imports the certificate to his > personal PC and started doing transactions. > > He shouldnt be able to export/backup the private key or the > certificate I have issued to him. So it is not only of concern who is performing those transactions (i.e. who is authorized) but what kind of tool (PC) he uses? Or where the PC is geographically located? As I understand you would like to bind part of security (or authorization?) to something different than a key. The key shall ensure someones identity (authentication). Now you want to prevent a backup of the PC. Since disk imaging is trivial, you have to use some key store hardware that cannot be copied (such as a SmartCard or token). Of course this can be moved (to a different location / PC). Even if it couldn't be, it is trivial to bypass, for instance by installing VNC remote display or set a remote DISPLAY via SSH to run the tool remotely on the `authorized PC' from some other PC or mobile phone (VNC client) from another location. I think you have to solve this by contract. Persons authorized to do such transactions, before have to sign a contract that explicitely states that the person never ever will access it remotely, in any way not intended or specified or perform a backup etc pp (hope a laywer can help). > Also this is not an issue in IE , as I can disable the option to export the > private key.So in IE, this requirement works well. > But I cannot enforce the agents to use Windows/Linux or IE /Mozilla.The > agents have the choice of infrastructure they can use.So I cannot enforce > them to use IE or Windows. But you can enforce them not to use Acronis Disk Image, VNC or VMWare? oki, Steffen --[ end of message ]--->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Problem with certificate generated from request
* Konstantin Ivanov wrote on Sun, Jun 28, 2009 at 11:25 -0700: > You connection to 127.0.0.1 is encrypted with 128-bit > encryption. However, this page includes other resources which > are not secure" > > Please note that I only get this message if I've placed by CA > root certificate into Trusted Certificates under windows. If I > remove CA certificate from trusted, what happens is that the > message regarding connection goes away but the identity is not > verified, which is normal as no root CA is present to validate. (probably it is not warning about `other resources which are not secure' if the whole page is not secure because the identity couldn't be verified) > What could be the problem of this? maybe there are some pictures in the page loaded via HTTP? oki, Steffen --[end of message]->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Creating certificate from meta data
* Mirko Velic wrote on Wed, Jun 17, 2009 at 20:21 +1000: > I was wondering if i could convert the data outputted by this command: > openssl x509 -noout -fingerprint -text < test.cert > info.txt > > Back into a certificate after I modify it, as it would make it easier to > generate certificates. You mean, you consider it easier to manually calculate an updated signature manually and edit its hex representation than using a signing command?! oki, Steffen --[ end of message ]--->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: about the integer decomposition
* Stephan V Bechtolsheim wrote on Fri, Jun 05, 2009 at 18:20 -0700: > > This is hardly anything remotely resembling a formal proof, > > of course. But it should give you the basic idea -- it's a > > difficult problem because the numbers are big. > Your argument only applies to "your algorithm". The question is > whether there exists something else besides a trial / brute > force / clever brute force approach. If I understood correctly, there is an algorithm known that solves it in polynominal time, the Shor-Algorithm, which is running on any suited quantum computer :-) Some other algorithms for machines able to run non-deterministic algorithms would also be possible I think (I'm not sure if this is really true that having a non-deterministic-machine would be sufficient. Is it?). So I think it is a difficult problem because the numbers are big and the computers are small :-) oki, Steffen About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS w/LDAP - SOLVED
(OT) * Michael S. Zick wrote on Sun, May 31, 2009 at 08:05 -0500: > A more general solution would be: > > # Am I running as user 0 (root)? > uid=$(/usr/bin/id -u) 2>/dev/null > if [ $uid == 0 ] ; then BTW, shouldn't it be just one "=" (to be compliant with POSIX and /usr/bin/test)? oki, Steffen --[ End of message ]--->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question about x509
* loody wrote on Fri, May 22, 2009 at 21:51 +0800: > 2009/5/22 David Schwartz : > > > >> Dear all: > >> at the end of letter, I append the the public key I excerpted from my > >> certificate by openssl x509. > >> Since the key is 2048 bits, 256 bytes, I find the length of > >> 00:af:..14:f7 > >> is 257 bytes. > > > > Right. In BER/DER form, without the leading 00 byte, the high > > bit is set and the number is negative. > Is it possible for RSA public key to be negative? > As far as I know, the numbers used in RSA should by positive, right? > so my certificate may be wrong? Your value starts with 00, so it is not negative, which was the initial question I think :) oki, Steffen About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: On the fly certificate generation to send to the client
* AngelWarrior wrote on Wed, May 20, 2009 at 15:18 -0500: > "I dont need to know with whom I am contacting but after > contact my messages should be private." If you sent your message to just anybody, how can it be private? oki, Steffen --[ End of message ]--->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: On the fly certificate generation to send to the client
* Scott Gifford wrote on Wed, May 20, 2009 at 21:52 -0400: > AngelWarrior writes: > > > but this still requires a CA kind of certificate right.I dont > > know if the client will be have a CA certificate to > > authenticate it.If I am wrong please explain me how it can be > > done. > > Regular SSL only requires a certificate on the server. > Encrypted Web browsing with https, for example, doesn't require > a client certificate. I think this is just a matter of configuration. Someone may run SSL without any certificate and even without encryption - for whatever this should be good for :-) (If only the server has a certificate, often additionally some other authentication and authorisation is needed, for instance some PIN or TAN). oki, Steffen ---[ End of message ]-->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Reverse ssl
* Victor Duchovni wrote on Mon, May 18, 2009 at 13:53 -0400: > On Mon, May 18, 2009 at 10:24:55AM -0700, Kyle Hamilton wrote: > > 'reverse SSL'? > > > In other words, the TCP initiator and passive listener are not > necessarily also the SSL client and server respectively. I think stunnel already supports this (at least in inetd mode). oki, Steffen --[ end of message ]--->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL attack scenario
* Nikos Balkanas wrote on Mon, May 18, 2009 at 15:29 +0300: > Wikipedia is right in principle, but doesn't cover the case of TCP > hijacking. I think this is out of scope, TCP is said to be reliable, not neccesarily secure. oki, Steffen --[ end of message ]-->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: I want you to do my homework for me.
* David Loman wrote on Wed, May 06, 2009 at 11:21 +0200: > Mods: Any way there can be some banning happening soon? Don't feed the trolls. oki, Steffen ---[ end of message ]->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Basic functions, again...
* Sever P A wrote on Mon, Apr 27, 2009 at 10:49 +0200: > > (Steffen said:) I think stunnel could be suited well here. > > Maybe... but my idea was to implentent this functions in the > C/C++ programm while the users has no computer expertise > skills. > > I suddenly thought to integrate this in a batch file but... I > don't really like this because complicates a bit more the > client pack installation. I think it is wrong to consider a batch file calling an practice-proven tool more complicated than developing all the tool again and integrate it! > But... what I exposed, is it doable ? Generally it is strongly disencouradged to invent and implement own security schemes. The more secure way is to use existing crypto schemes (like TLS) and the safer way is to base on existing implementations (like stunnel), I think. There are so many things to consider (actually it is a somewhat frequent topic here I think :)), things that could be implemented incompletely or wrongly... oki, Steffen About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Basic functions, again...
* Sever P A wrote on Sat, Apr 25, 2009 at 13:35 +0200: > I don't reach to understand how to implement all this steps. So: I think stunnel could be suited well here. oki, Steffen About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Open SSL via dyndns.org
* tobias.sem...@diemer-ing.de wrote on Tue, Apr 14, 2009 at 15:04 +0200: > Is there a chance to create a certification on the intern server called by > the extern https://name.dyndns.org adress ? It depends on the software you are using and on the setup... If you use some non-routable IP for your LAN (internally SRV02) and another IP on this server for the dyndns.org name, I think this should be possible. With Apache, you could create two instances based on IPs. One instance could be bound to the internal IP using the SRV02 certificate, another default one with the other certificate. Of course it is possible to use name.dyndns.org also internally (for instance, by adding this to the internal DNS pointing to the internal IP, which usually has restrictions and limitations). oki, Steffen End of message. --->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.0 beta 1 released
* Dr. Stephen Henson wrote on Thu, Apr 02, 2009 at 13:01 +0200: [...] > Under this scheme > > 1. Bug fix releases will change the letter. >E.g. 1.0.0 -> 1.0.0a > > 2. Feature releases will change the last (minor) number. >E.g. 1.0.0 -> 1.0.1 > > 3. Major development will change the second (major) number. >E.g. 1.0.0 -> 1.1.0 Is the new scheme really 1.[major].[minor][letter] this would be different to the probably common [major].[minor].[...] scheme (which does not need confusing letters at all :)). BTW, I think after 0.9.9 the natural successor could be 0.9.10 or 0.10.0. oki, Steffen End of message. --->8=== About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Bad Decrypt message when using -pass pass:
Hi all! * Nickfx wrote on Wed, Feb 11, 2009 at 08:54 -0800: > Crazy I know. Having removed split, Openssl is now working as > it should. It would seem that there is something screwy with > Cygwins Split or Cat command. I rember that I had trouble because DOS/UNIX line feed translation was performed by cygwin. I was surprised because I consider automatic line feed translation on pipes very doubtful and as I understood the documentation of the environment variable CYGWIN `binmode' should be default and most shells should apply `binmode' to pipes also. This lead to broken `make dist' (automake) because of some unwanted `tar | gz' CRLF conversion I could imagine that you have a similar issue. The size of missing data roughly fits the expectation to map CRLF to LF (65534/65536 ~ 18995/19000 of course heavily depends on the data). oki, Steffen --[End of message]->8=== -- About Ingenico: Ingenico is the world’s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [OT] PermitRootLogin is Missing in /etc/ssh_config
Hi all, * Charles Darwin wrote on Sun, Feb 08, 2009 at 09:27 -0500: > Any idea? (This is off topic here) Shouldn't it be in /etc/sshd_config (or /etc/ssh/sshd_config)? And if missing there, why not simply add it?! oki, Steffen ps.: is this your real name or is it because of the `Darwin Year 2009'? ===8<-[ End of Message]--- About Ingenico: Ingenico is the world's leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL command line HMAC
Hi all! * Dave Thompson wrote on Fri, Feb 06, 2009 at 20:59 -0500: > > Adding the quotes didn't work because, if I understand things > > correctly, the notion of quotes (or escaping characters with \) > > is a shell concept - hence my attempt to force the command to run > > under a shell. > > > Those are shell concepts, yes. The parameter was wanted to be passed as it is and to be able to quote a shell was used? I think, quoting is to avoid that a shell interprets parameters, so I think in best case ending up with passing as it is (i.e. not evaluating). Also splitting parameters at word boundaries is a shell concept. That's why Javas Runtime.exec() has a `String[] cmdarray'. I guess cmdarray[0] is the command binary, cmdarray[1] the argv[0] and cmdarray[2] the first parameter (fortunality the Javadoc[1] does take the fun letting the developers guess, but it states that exec() executes, cmdarray is the command and envp the environment, who had guessed that! SCNR). So for passing arguments as it is a shell is not suited. > Shell is designed to be convenient for normal (interactive) cases, > as the cost of confusion and obscurity in weird cases. [I wouldn't call it `interactive or confusing', there are a lot of useful shell scripts also :-)] oki, Steffen [1] http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#exec(java.lang.String[],%20java.lang.String[]) ---[ End of message ]-->8=== About Ingenico: Ingenico is the world's leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL command line HMAC
Hi all, Hi Alistair!
* Young, Alistair wrote on Fri, Feb 06, 2009 at 10:16 +:
> Ultimately I settled on the use of a shell script to act as an
> intermediary:
>
> #!/bin/bash
If you can use bash you could pass the key in \xNN form for
$'\xNN' to avoid special characters like blanks and control chars
or binary zero issues:
pass a kind of hey dump instead of binary.
First make some "escape hex dump" with something like
public static char[]
getbin(byte[] buf)
{
char[] result = null;
int pos = 0;
int len = buf.length;
{
String result = "";
result = new char [len * 2];
for (int i = 0; i < len; i++) {
byte b = buf[pos + i];
// this is horrible slow because of many temp StringBuffers,
//just to illustrate
result = result + "\\x"; // we want \x in the String
result = result + hexnib((b & 0xF0) >> 4);
result = result + = hexnib((b & 0x0F));
}
}
return result;
}
public static final char
hexnib(int nibble)
{
if (nibble <= 9) return (char) ('0' + nibble);
return (char) ('A' + nibble - 10);
}
For 'hello' you should get '\x68\x65\x6c\x6c\x6f'.
Then pass this to your script as parameter like you now pass the
file name and in your script have something like
#!/bin/bash
key_escaped="$1"
key_raw=`eval echo $\'$key_escaped\'`
echo openssl -option "$key_raw"
which can be used like
u...@host:~ $ ./x.sh '\x41\x42'
openssl -option "AB"
(This does not mean that I'd recommend to do such things! Crypto via
shell scripts and stuff invitest potential security flaws etc.)
oki,
Steffen
[End of message]->8===
--
About Ingenico: Ingenico is the world's leading provider of payment solutions,
with over 15 million terminals deployed across the globe. Delivering the very
latest secure electronic payment technologies, transaction management and the
widest range of value added services, Ingenico is shaping the future direction
of the payment solutions market. Leveraging on its global presence and local
expertise, Ingenico is reinforcing its leadership by taking banks and
businesses beyond payment through offering comprehensive solutions, a true
source of differentiation and new revenues streams.
This message may contain confidential and/or privileged information. If you
are not the addressee or authorized to receive this for the addressee, you must
not use, copy, disclose or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you for
your cooperation.
P Please consider the environment before printing this e-mail
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: unexpected SSL_ERROR_ZERO_RETURN
* Md Lazreg wrote on Thu, Jan 08, 2009 at 15:11 +0100: > The problem in my case was a server one. I use a non-blocking socket for the > server to receive information from the clients, so the server performs a > select with a timeout of 1 second to read information. It turns out that > when they are network issues, 1 second is not enough and the select times > out with a 0 return value, so the server was assuming that the client is > gone and closes the connection > > Now, when the select times out I check the errno and if it is EAGAIN, I try > select again... This solved the problem and all clients now are handled > correctly... > > What confused me is the man select documentation which states that select > sets errno only if the return value is -1... it seems that even if it > returns 0 errno might be set... > > I have seen this problem on Linux and Hp platforms... errno always has a value. It might be defined (if a function returned -1) or a `random' value (such as 11, EAGAIN or whatever, usually highly predictable :)). My man page seems to be very clear about select timing out with a 0 return value: RETURN VALUE On success, select and pselect return the number of descriptors contained in the descriptor sets, which may be zero if the timeout expires before anything interesting happens. I think usually the `client is gone', `connection closed' or `end of file' situation is when select(2) does return `read for read' for this file descriptor and read(2) returns zero [from man 2 read: `On success, the number of bytes read is returned (zero indicates end of file)']. oki, Steffen -- [end of message. please ignore the rest of this mail] --->8=== About Ingenico: Ingenico is the world's leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Which version of 0.9.9 is stable enough to use?
* Vishnu Param wrote on Mon, Nov 17, 2008 at 16:12 +0800: > > > s3_enc.c:(.text+0xaeb): undefined reference to `COMP_CTX_new' > > I am sure I am pointing to the 0.9.9 libraries/headers, because I > wouldn't get these errors if I wasn't. I think what you were supposed to ensure is that you have the right headers; maybe you have system-wide installed older in -isystem. > Invoking: GCC C Linker > > gcc -static -L/home/zero/test/lib -o"SSLclient" ./client.o > -lcrypto -lpthread -lssl -static with glibc? I think at least resolver remains using dynamic linking... > dso_dlfcn.c:(.text+0x2d): undefined reference to `dlopen' ... and this module also seem to use dynamic linking. -ldl (for the others I don't know) oki, Steffen -- About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: how to run gdb in openssl
* prashanth s joshi wrote on Tue, Oct 07, 2008 at 21:13 +0530: > Could anyone please tell me how to run the gdb in openssl? > In gdb I am running the command as path_of_bin/bin/openssl s_client -connect > ipaddress:4433. > But i get the error as: Undefined command: "". Try "help". > why is it so? Because "path_of_bin/bin/openssl s_client -connect ipaddress:4433" is not a gdb command? [EMAIL PROTECTED]:~ # gdb /usr/bin/openssl [...] (gdb) set args s_client -connect ipaddress:4433 (gdb) r Starting program: /usr/bin/openssl s_client -connect ipaddress:4433 gethostbyname failure connect:errno=2 Program exited with code 01. (gdb) Try `man gdb' for details :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to use a hardware RNG with openssl?
Hi, thanks a lot for your detailed explanation. * Lutz Jaenicke wrote on Fri, Sep 19, 2008 at 16:46 +0200: > OpenSSL's internal PRNG uses a 1024 byte pool mixing entropy with > SHA-1 so the more bytes a mixed in, the better. At least it cannot hurt > to add any input to it as the entropy in the pool can never decrease > by mixing in more bytes. ok, I just think that at least the last sentence is not neccesarily correct, namely when the entropy sources depend on each other. I guess if SHA-1 is assumed perfect here (and because of the kind of mix which is using it) it might be impossible to construct the data dependency in a way to abuse that because no reversion of SHA-1 should be know, so practically no impact. But in another (general) case it could harm, for instance in worst case the mix function could be an XOR and the dependency of input sources could be a symbolic link, leading to infinite zeros as entropy. Of course this is very artificial, but maybe other dependencies could lead to a weakness of entropy when mixing it with dependent/derived entropy? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How to use a hardware RNG with openssl?
* Lutz Jaenicke wrote on Fri, Sep 19, 2008 at 14:22 +0200: > > we purchased a hrng for the generation of RSA keys for instance. > > It is an USB device an shows up as /dev/qrandom. > > > Note: if /dev/urandom is available, OpenSSL will read an additional amount > of random bytes from it whether an explicit seed source is available or > not. This however does not reduce the quality of the entropy provided > by your source. > > > I am not shure about the role of /dev/urandom: does it deliver a > > (pseudo) random number or the salt for the PRNG? > > It is used to seed OpenSSL's internal PRNG. This means the internal PRNG is seeded with /dev/urandom data, but it is not used at all and /dev/urandom is not used elsewhere (if external entropy source is used) -- is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [FWD] Re: Convert a DER certificate to PEM certificate
* Lutz Jaenicke wrote on Tue, Aug 12, 2008 at 08:47 +0200: > Please help me with the command line to convert a DER > Certificate to PEM Certificate. $ openssl x509 -inform der -outform pem < certificate.der or $ openssl x509 -inform der -text < certificate.der (which includes a human readable description before the PEM block) > Also please confirm when I convert it to PEM will the > certificate have the private key or not. (your certificate certifies the /public/ key of course, as the private key should not be published but kept private, check with `openssl -text') oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl-users] Re: Which datatype for passphrase?
* Konrad Kleine wrote on Fri, Jun 13, 2008 at 17:32 +0200:
> One of our principles is to have only one exit point in
> functions, so in this point we would agree with you. On the
> other hand, it is also possible to do it without "goto"s.
Yes, it is possible to `goto' without `gotos', sometimes there is
some code like
allocate_stuff();
do {
if (!action1()) break;
if (!action2()) break;
if (!action3()) break;
} while(0);
free_stuff();
which may be considered a `hidden goto', maybe done because some
keyword-based metric forbids using the keyword `goto', but I think
logically it is the same.
Since it is hidden personally I dislike this.
Better clearly writing goto than emulating goto!
Using a pattern like
allocate_stuff();
if (!err) err = action1();
if (!err) err = action2();
if (!err) err = action3();
free_stuff();
in certain circumstances may also not be suited.
Having some `func_exit:' label IMHO can improve readability of
code (which is important to ease code reviews, for instance).
So in short I think goto should not be demonized unconditionally;
it depends on how it is used. just needed to say that :-)
BTW, for passphrases to be entered by humans (without binary zeros
inside) I think C-strings could be suited, the data type for some
entry function could be `char *const passphrase' and for some
function that uses it maybe `const char *const passphrase'. Is
that right?
oki,
Steffen
--
About Ingenico Throughout the world businesses rely on Ingenico for secure and
expedient electronic transaction acceptance. Ingenico products leverage proven
technology, established standards and unparalleled ergonomics to provide
optimal reliability, versatility and usability. This comprehensive range of
products is complemented by a global array of services and partnerships,
enabling businesses in a number of vertical sectors to accept transactions
anywhere their business takes them.
www.ingenico.com This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on this
message or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Wider fallout from Debian issue?
* John Parker wrote on Sat, May 31, 2008 at 15:35 -0500: > > Probability that a "proper" key falls in the space of the > > "bad debian" keys: 2^15 / 2^2048 = 1 / 2^2033. > > > > That's a lot of zeros before the first non-zero digit. > > Put differently, if you were to start generating keys now at a rate > of, say, 1000/s, how long would you have to wait before you got one of > the Debian keys? This is a fun math problem for probability theory > students. wow, big numbers, John! Cool idea to make such a time estimation :) Maybe we should say `a million keys per second', sounds much more but just are three digits less in the result :) Is the calculation that complicated? Aren't the keys independent of each other, so that each key always have the same probability, since we are not `searching' but `guessing' when generating? (beside, that all those values are so horrible big that practically it does not matter of course :-)) With Victor's number of 2013 bits probablility, couldn't we statistically expect half of that? With a million per second does this give (2^2012) / 10^6 / 60 / 60 / 24 / 365.25 years which the 593 digit number 14902094353953870165214353410981143707238235188212334084836694330488\ 81602740116106914618746657670317636941551690018457525299578948872878\ 36765806488289940028625838604817603080995646449473721456572544453618\ 55782431446798772374819591436871325406930507575507226972337350924070\ 18286766525605611643878663746554436287030227901811414516143083673080\ 28892637223535933402770689260083725677906317276399679998875094201786\ 41124284757024653658707346461288521262653417342296719918707161098486\ 04762949019240046008945125630714069482285597143371578237868834348990\ 3212246280855279993597997641265155474006217516831 of years? Seems there even is a number word[1], so are that around a hundred quintillion nonagintacentillions? lol Assuming the age of the universe beeing 13.73 * 10^9 year (http://en.wikipedia.org/wiki/Age_of_the_universe), (2^2012) / 10^6 / 60 / 60 / 24 / 365.25 / (13.73 * 10^9) or `in short': 10853673965006460426230410350314015810078831164029376609495043212300\ 66717217855868109700470981551578759607830801178774599635527275216954\ 38285365250029089605699809617492791756005569154751435875143877970588\ 89863387798105442370589651447102203501041884614353406389175055297938\ 95329036071089301998454962670469363646780938020255946479346747030648\ 42602066441031269776235024952719392336421207047632687544701452441213\ 70083237259304190574440893271149687736819677598176780712823860960295\ 73753058280582699205349690918218550242014273228966917871718014820823\ 249253188700311725680844693464323049818 universe ages would be needed, slighty more than 10^582, which is a funny big number... Even when using `googols' (10^100) as factor it remains terrible... lol SCNR. oki, Steffen [1] http://en.wikipedia.org/wiki/Names_of_large_numbers#Extensions_of_the_standard_dictionary_numbers About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wider fallout from Debian issue?
* [EMAIL PROTECTED] wrote on Fri, May 30, 2008 at 06:51 -0500: > Back in the day, DES was the de facto encryption algorithm. [...] > In an ideal world, I think the system should throw an exception > then and let the calling application feed it another key. > However, I think the general consensus was that we should just > ignore it. I don't know what the general consensus was, but applications I know do not ignore this situation but handle it by actively rejecting it. Do you meant this by `ignore'? I think best is to consider a weak or semi-weak [3-]DES[1] key as a [3-]DES key acceptable and thus refuse to generate, store or use it[2]. In practice usually it shouldn't be a big deal to iterate a 16 elements table at key generation, which probably usually is much more expensive. So to say that DES is not defined / allowed for those numbers (keys). I think it is a little like division by zero: it simply cannot be done. BTW, testing that can be difficult and probably needs special considerations (e.g. some test driver with special `PRNG without random' generating bits that lead to a weak key to check if the generator correctly detects and refuses it). oki, Steffen [1] A 3DES key with one weak or semi-weak key half should be considered weak (not essentially stronger than single DES). [2] http://en.wikipedia.org/wiki/Weak_key tells as a main countermeasure: `Checking generated keys against a list of known weak keys, or building rejection of weak keys into the key scheduling.' About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wider fallout from Debian issue?
* Victor Duchovni wrote on Wed, May 28, 2008 at 21:10 -0400: > > > Only against random attacks of course, if all attackers > > > first check these keys, then removing them strengthens the > > > algorithm against (non-random) brute-force attack. This > > > said, the effort of explicitly avoiding these is probably > > > wasted (unless one suspects one has a identically weak > > > RNG). I think blacklisting those keys on a strong system reduces the key space (even if it just the smallest bit of a bit) and thus helps the attacker, because she don't need to try those keys. In this particular case I would expect an attacker testing those `frequently existing' keys first (in the hope/expectation to hit from time to time a key generated with such a valgrind-SSL :-)). Noone requires brute-force to use a random probe order :-) If assuming that because of this all RSA brute force attacks try those keys first in all future, someone may wish to avoid such keys (accepting a small decrease of key space). On the other hand, someone else could assume that all potentially weak keys are regenerated and the concerned (boxes, systems, admins, security professionals, ...) now are more sensitive, carefully exchanged all keys against, installed IDSes scanning the network traffic for traces of weak keys and this time double-verified everything, including exhaustive use of all the black-hat attack tools to test themselfs, and from that conclude that it makes no sense to check that keys at all because noone will ever use them and if someone accidently created one, security test tools will alert `potential valgrind-SSL key' or alike. (I would start searching those `frequently existing' keys :-)) Does this make sense or am I wrong? A complicate topic I think, and very interesting :) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wider fallout from Debian issue?
* Deane Sloan wrote on Thu, May 29, 2008 at 04:47 +1200: > stated, the overall risk of generating such a key on an unaffected > system is (extremely?) small for the security that a 2048bit RSA private > key is intended for? The risk to generate one specific key of 2^16 (or how small was the key space?) should be `roughly the same' compared to 2048 Bit RSA, as to generate one specific key (when assuming perfect strong generation). That means, the risk that you accidently generate exactly the same key as I generated is of almost the same order of magnitude. This also was acceptable before the debian issue :) Of course you are right, this probably happens all few billion years in one of the known universes and theoretically it could even happen with the key you are generating right now :-) If someone would not accept the risk of randomness / entropy with their properties, using cryptography in this case probably would be no option, but I think in all `practical situations' such extremely unbelievable rare events (as strong key generation producing collisions) should not be overstated. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: The rules of SSL-Certificate validation?
* Lutz Jaenicke wrote on Tue, Apr 22, 2008 at 09:59 +0200: > > This rule is independent of current time. e.g. If the validity dates > > of the parent certificate is 2008/04/18~2009/04/18 and the ones of > > child certificate is 2008/06/18~2009/06/18 or 2008/03/18~2009/03/18, > > the certificate chain should be invalid. The validity dates of child > > certificate should be between the ones of parent(2008/04/18~2009/04/18). > Ok, so we are facing a violation of policies at the CA. At the date of > certificate verification we are however checking whether all components > of the certificate chain are valid at this day. > Even though the overlapping dates are a violation of the standard the > question is whether we actually should actually enforce this inside the > library. Yes, maybe then a new CA certificate will be presented (with new expiry dates), why not. BTW, what is the idea/logic behind? I don't understand why this should be independent of current time. Maybe before the CA certificate expires, a new CA certificate will be presented without overlapping validity. Also, if the child certificate would be trusted if valid till 2009/04/18 on 2009/04/17, I don't see why it should not be trusted at the same day (2009/04/17) if valid till 2009/04/19. I understand that in the second case the CA certificate is not trusted anymore, but this surely does depend on current time. I've already read the idea that a CA should not certify for longer than a certificate that is valid for the signing key - but never understood why. Is this some standard requiring that or is it just a matter of policy (and style maybe)? Where can I read/learn more? Beside useless and expensive, wouldn't it be allowed (correct) if the CA every day creates a new one-day-valid CA certificate? Can it really be concluded from the expiry date of some certificate whether the CA is authorised to certify or not? What if the CA is authorised to certify for four years with a maximum certificate duration of 30 days? (or whatever some policy requires). If it is just against the policy of some CAs and other reaonable policies could be imagined, I think it should not be checked by the library. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Openssl loading
* Li, Yvonne wrote on Fri, Apr 18, 2008 at 23:46 -0400: > You have lots of good points. Thank you again. > > I work for AOL, developing cross platform SDK for instant messaging that > supports plugins. Plugins can be malicious. And AOL is responsible for > protecting users' identity and privacy. Considering our user base, a > trojan is more likely to target our users than to protect them. So in short, you cannot trust the environment you run some SSL based application in, right? Because it is the same environment other plug-ins can do whatever they want? In that case I'm afraid you're lost. You cannot create a secure something inside a trojan horse environment I think. First, you application that verifies whatever can be modified when loading or replaced completely (who can replace libs, probably can also replace binaries). Second, your trust database (e.g. root CA certificate or alike) could be replaced (e.g. by intercepting the open/read system calls or whatever). Some malicious CA certficate could be put in place. I could imagine that this is easier than trojaning platform-dependent openssl libs in version-dependent internet tools and even would work for web browsers :) > What do the majority applications do on Unix if static linking > with openssl isn't suitable? For security reasons, I think here is should be suitable, because if there would be some security issue with openssl or any other used library or system package, even after the unix vendor / linux distributor online-update-mechanism installed a fixed openssl lib, a static linked application would still be vulnerable! oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Convert binary to hexadecimal, and string storing hexadecimal to hexadecimal
(OT)
* Badra wrote on Fri, Apr 18, 2008 at 17:03 +0200:
> I have also unsigned char B that stores a binary value. I need to
> convert it to hexadecimal, I do:
>
> char *table = "0123456789abcdef";
> int i;
> for (i=0; i {
> B[2*i+1] = table[B[i] & 0xf];
> B[2*i] = table[(B[i] & 0xf0) >> 4];
> }
>
> The above two converts work correctly.
Sure?
You have a `unsigned char B', that usually is a 8 bit value and
invoke strlen on it? Do you mean a `const unsigned char*'
pointing to binary data?
Still, it would convert excluding first 0x00 byte. But I think it
is worse than that.
--->8===
1 #include
2 #include
3
4 int
5 main(void)
6 {
7 unsigned int guard = 0xdeadbeef;
8 const unsigned char B[] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06,
0x00, 0xff };
9 char *table = "0123456789abcdef";
10 int i;
11 for (i=0; i> 4];
15 }
16 assert(guard == 0xdeadbeef);
17 return 0;
18 }
===8<---
# gcc -ggdb x2.c
x2.c: In function `main':
x2.c:13: warning: assignment of read-only location
x2.c:14: warning: assignment of read-only location
# gdb a.out
(gdb) b 12
Breakpoint 1 at 0x80483d7: file x2.c, line 12.
13 B[2*i+1] = table[B[i] & 0xf];
(gdb) p /x guard
$1 = 0xdeadbeef
(gdb) p /x [EMAIL PROTECTED](B)
$2 = {0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x0, 0xff}
(gdb) cond 1 (i>7)
(gdb) c
Continuing.
Breakpoint 1, main () at x2.c:13
13 B[2*i+1] = table[B[i] & 0xf];
(gdb) p /x guard
$3 = 0x3133
(gdb) p /x [EMAIL PROTECTED](B)
$4 = {0x30, 0x31, 0x33, 0x31, 0x33, 0x33, 0x33, 0x31}
here, the stack already is overflowed. strlen(i) is something undefined
because no EOS zero anywhere in B.
(beside the fact that B contains wrong data, I think
0x30, 0x31, 0x30, 0x32, 0x30, 0x33, was intended)
(gdb) d 1
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x400969b0 in strlen () from /lib/i686/libc.so.6
0x400969b0 in strlen () from /lib/i686/libc.so.6
(gdb) up
#1 0x080483cd in main () at x2.c:11
11 for (i=0; ihttp://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: SSL overhead
* Tomas Neme wrote on Wed, Apr 16, 2008 at 17:44 -0300: > The problem is that SSL_pending might return 0 if there's > stuff on the socket, but isn't enough to decode a full record. If you want SSL to be transparent, why are you interested in intermediate protocol-specific data which would not be returned by SSL read anyway? (isn't calling SSL_pending in the loop and if so, calling SSL_read() to get the data what you need to do?) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: authentication then authorization
* Kyle Hamilton wrote on Thu, Apr 10, 2008 at 02:34 -0700: > > (That means the CA remotely signs online submitted CSRs and sends > > back a Cert immediately? Maybe such a CA would not be that > > trustworthy...) > > First: it is as trustworthy as the application seems to > require. It's not as though these certificates are going to be > trusted by anything outside of that application realm, and thus > the CA key exposure risk is minimal. Yes, of course, it depends. In a scenario where a closed group of entities, each able to securely (enough for this application) communicate something to a CA, this may work very well. Maybe it is not clear why a CA is even needed. > I'm sick of hearing "best practices" being parroted about without > regard for, y'know, actual security evaluation. Security is often > what makes systems unusable. On the other hand, I'm afraid, `a little bit of security' may work only as long as there are sufficiently other services easier to attack. I mean, why attacking some SSL protected web shop if users open phishing mails or alike. But situation may be different when everyone use `a little bit of security'. For instance, there are so many people using HTTPS servers with X.509 certificates that the presence of some key or lock symbol in a browser status line may not tell much. How many people read the subject information of a certificate before starting online banking? Your points are correct of course. If hyper-secure online banking is too unusable complicated and uncomfortable noone would use it :) > It's people who parrot these 'best practices' without regard for > reality that end up reducing the usage of cryptography, because they > ignore the fact that end-users don't care about security -- they care > about using the systems they have access to in the way that they need > to make use of the systems. They don't care about 'following policy', > they care about 'getting their jobs done'. Yes, but as soon as they are attacked they ask why their secure application was not automatically secure and may ask, if this and that can be done insecure why the application does not prohibit it etc. I mean, if someone gets internet order deliveries he never ordered because of some attack he probably don't want to pay. I think it is part of the job of secured systems to `educate' users a little. For instance, the online login page of the bank I use shows different security hints like `Do never open banking links in email', `Check the key/lock and the URL before logging in' or `We never ask for a TAN at login' etc. I think this is good. > > Yes, then it is know if the peer's identity is authentic. For > > instance, that it is really is `Malicious Hacker' from China that > > is connected (and noone else can decrypt data sent to them :)), > > as the certificate correctly states, protected by strong > > cryptography... > > Authentication and authorization can be dovetailed into the > same step. Not necessarily in all circumstances, and there are > many circumstances within which it makes no sense -- but there > are also situations that are so simplistic and low-risk as to > not need the increased complexity. (increased complexity leads > to orders of magnitude more cost, due to the number of parts > that have to be tested in all of their possible combinations.) Yes, sure. But for very simplistic and low-risk tasks maybe no 4096 bit RSA key protected PKI is needed but a shared 3DES key is sufficient or so (of course I see that using SSL may still be suited because it is standard, well-known and easy to use). > > Without authorisation this probably would be too weak. Often it > > might be needed to find out if the identity / entity that is > > connected (and authenticated) is authorised to use the particular > > service. > > This is where protocols like Kerberos and ADFS come into play -- but > if one is not trying to integrate into these service structures, these > protocols can also be ignored. (or simply check if the DN matches some whitelist) > Fortunately for the rest of us, we don't need that level of paranoia > to use cryptography in our day-to-day lives. We usually don't handle > transactions of that large of a scale, and quite often we don't handle > "transactions" at all. We just want to communicate, and sometimes we > don't want the rest of the world to see that we typed "I still love > you and sometimes still dream about you" to our ex-girlfriends or > ex-boyfriends... but if someone's current girlfriend gets a signed message from his ex-gf claiming he met her last night (which in real is from someone else who has interests for the current girlfriend) and the current girlfriend leaves because of that (or vice versa for boyfriend), people probably would blame the messaging tool for beeing insecure. In talk shows girls told that they left boyfriends because of messages in mobile phones or instant messager history, so I think this can happen for faked sig
authentication then authorization
* Kyle Hamilton wrote on Wed, Apr 09, 2008 at 14:22 -0700: > Each peer goes through this process: > 1) peer creates a keypair > 2) peer generates a CSR (certificate signing request) for its public key. > 3) peer connects to server, submits CSR along with whatever > information necessary to determine that the certificate should be > issued. > 4) Server signs the certificate with its private key, and sends signed > certificate back to peer. peer and server disconnect. (That means the CA remotely signs online submitted CSRs and sends back a Cert immediately? Maybe such a CA would not be that trustworthy...) > Then, on peer-peer connection: > 1) peer(listener) presents its own certificate, requests > peer(connector) certificate from same CA. > 2) peer(connector) verifies peer(listener)'s certificate (and proof > that it has the private key paired with the pubkey in that > certificate), presents its own certificate. > 3) peer(listener) verifies peer(connector)'s certificate (and proof > that it has the private key paired with the pubkey in that > certificate). > > Each peer has a copy of the CA certificate in its trusted root > authorities store. When they receive a peer certificate, they verify > the signature on that certificate as being from that CA, and then > verify that the peer that it's talking with actually has the private > key associated with that certificate. Then they look at the > information in that certificate (expiration date, etc). > > This is what TLS with client authentication does. Yes, then it is know if the peer's identity is authentic. For instance, that it is really is `Malicious Hacker' from China that is connected (and noone else can decrypt data sent to them :)), as the certificate correctly states, protected by strong cryptography... Without authorisation this probably would be too weak. Often it might be needed to find out if the identity / entity that is connected (and authenticated) is authorised to use the particular service. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Problem after removing memory leak
* Wockenfuß, Frank wrote on Wed, Apr 02, 2008 at 09:07 +0200:
> Thank you for that hint.
> I will try to rebuild the class as singleton. This could help,
> but isn't really nice.
I think you'd need multiple classes. For things done once a
program life time, a C++ class (singleton) may not be suited, a
simple ordinary init function may be sufficient. However, such an
instance could make sense for instance if used on stack around
main in something like this:
int main()
{
OpenSSLAllEverything allocation;
return main_();
}
to ensure that it is released exactly once even in case of
exceptions. Maybe the class assert()s that it is constructed only
once to help application developers to find usage problems
quickly.
I think it is essential and required to call RAND_seed once and
only once. Functions like X509_verify_cert may be desired as
X509Certificat::verify().
> > Doing it per-object creation is unnecessary and error prone
> > (as maybe the case here). I believe it should be possible to
> > do it once per program lifetime without changing your C++
> > class too much.
Maybe having a static instance counter, so resources could be
freed if the last instance is destroyed? But to much automagic
handling may not be good; imagine, this would be linked with a
similar class that also has its own instance counter...
oki,
Steffen
About Ingenico Throughout the world businesses rely on Ingenico for secure and
expedient electronic transaction acceptance. Ingenico products leverage proven
technology, established standards and unparalleled ergonomics to provide
optimal reliability, versatility and usability. This comprehensive range of
products is complemented by a global array of services and partnerships,
enabling businesses in a number of vertical sectors to accept transactions
anywhere their business takes them.
www.ingenico.com This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on this
message or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: CAFile
* [EMAIL PROTECTED] wrote on Wed, Mar 26, 2008 at 18:26 +0100: > For some hours now I try to find out how to create CAfile (a > file with multiple CAs inside, the one file counterpart of > -CApath). > > Could anybody please give me an example Not sure if I understand you right, but if you want to generate a `certificate bundle file' from several `PEM' X.509 CA certificates (files with "-BEGIN CERTIFICATE-" etc) you may try: $ cat *.crt.pem > ca-bundle.crt oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: own Certificate Authority: Renewal of CA cert
Hi, in short I think in your -signkey command you need to add -enddate. * Andreas Grimmel wrote on Mon, Mar 24, 2008 at 17:28 +0100: > > That depends on what you need to do by policy for renewal. > > There is no such thing as "technical renewal" - there is only > > policy based. Since this sounds like an ad-hoc CA without a > > formal Certificate Policy, you have some choices: > > > As I must admit, I never heard or thought of a certificate > policy. Does this mean a policy, set up by e.g. my company, > that defines how to enroll certificates in general, or is that > something what has to do with openssl itself? However, you're > right, we're talking about an ad-hoc CA for these terms. The policy is the definition how the people (roles) that are able to access (use) the secret/private CA (and other) keys have to use those keys, which usually includes certification and thus clear statements which certificate signing requests to sign, how to prove their authenticity, how to distribute them, what to do with CRLs etc > So the only thing to do is create a new CA cert using this same key and > the same credentials like ST, CN, and so on and enroll it to every client. > The Clients just reload their software to recognize the new cert, and > will just go on working as before. Yes, I think you will need to update the certificate(s) on each client if expiry dates are checked (I guess on PC Apps this probably is done in almost any case). > OK, that would mean to not only replace the CA cert, but also the > individual client cert on every client machine. Since I have to touch > the client machine in both cases, my advantage here would simply be to > have a new CA key, and nothing else, right? I think in your case, 4 years ago you missed to use a lets say 20 year validity of the CA cert. So I think now I wouldn't change the keys at all, just change the certificates (or its information). > This means even if the CA cert has expired, it's possible that > some clients would continue working until their own cert's > expiration day has come? > This is kind of funny... ;-) I think this depends on the application. Usually I would expect a CA not to sign for time intervalls exeeding the CA certificates validity. > Yes, this will be no big deal, now knowing that a renewal in technical > terms just doesn't exist. > But, If you allow me to ask this one more thing, I found this command > somewhere in a forum: > > openssl x509 -in cacert-old.pem -days 1460 -out cacert-new.pem -signkey > private/cakey.pem You probably want something like `-days 7300' and also `-enddate' is needed I think, so maybe something like: openssl x509 -in cacert-old.pem -days 7300 -enddate -out cacert-new.pem -signkey private/cakey.pem > - in my understanding, this command takes the old cert, changes the > validity to four more years (1460 days), and generates the new cert > signed with the same old private/cakey.pem - somewhat logically. But: > opposite to that, *I* would have used this command, as I did when > creating the original (old) CA cert: > > openssl req -new -x509 -days 1460 -key private/cakey.pem -out cacert.pem > > - means to just create a new cert using the same old private/cakey.pem > again. > > As I can see, the only difference would be that in the upper command, I > probably don't have to enter the ASN1 DN credentials like CN/ST and so > on again, since this would be taken from the old cert > Am I correct here? You may try it. The generated certificates can be viewed using openssl x509 -text -in cacert-new.pem I would not use `req -new', because maybe you accidently changed something in openssl.conf and you get a different CA cert. Of course this shouldn't happen because the policy should state the details but if you don't have one ;) At least I would expect that the certificate has a different serial number. with `-days 7300 -enddate -signkey' I would expect the same cert (except end date, hash, sig of course) > Right, that would really be kind of suspicious - it was just an idea of > being lazy and not needing to touch every client ;-) I'm afraid you need to update each because they check against a local copy of the CA certificate(s). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information he
