Re: [openssl-users] Means to update read bio only
On 2/7/2015 8:33 AM, Matt Caswell wrote: On 06/02/15 21:46, Matt Caswell wrote: On 06/02/15 15:48, Susan Hinrichs wrote: Hello, In Apache Traffic Server we are primarily using SSL_accept and SSL_read/SSL_write with file descriptor bios. But during the handshake, we need to feed in our own packets via read-only buffers. We use the BIO mem_buf to pass along this data without incurring another copy. But on each read during the handshake, we need to reset the read bio. We leave the write bio as the file descriptor bio the whole time. I originally tried to use SSL_set_bio(ssl, new_rbio, SSL_get_wbio(ssl)), but that would adjust the output buffering and the handshake would not complete. So we created a SSL_set_rbio(ssl, new_rbio), that just frees the old rbio and sets the new one. It leaves the wbio and the bbio alone. This has worked well for us for a couple releases, but looking forward to openssl 1.1, we will no longer be able to use this approach. Can someone point me to the preferred way of updating a read bio without affecting the write bio processing? H... that's a good question. I don't think you can set just the rbio by itself. I wonder if maybe we extended SSL_set_bio, so that you could do this: SSL_set_bio(s, rbio, NULL); I'll look into it. This would be a good item to add to Rich's wiki page. I've just pushed a new commit to master (1.1.0), that adds SSL_set_rbio, and SSL_set_wbio as new API functions along with some associated documentation. Matt Great! Thanks for the addition. I'll take it for a spin. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] AES-GCM failing from Command Line Interface
On Mon, Feb 09, 2015, Sec_Aficionado wrote: Hello, I am trying to encrypt a short message using AES-256-GCM as mentioned in the subject. My command is: openssl enc -aes-256-gcm -p -in payload.txt -out enc.txt I get prompted for password as expected. The encryption goes well, and then I proceed to decrypt using: openssl enc -d -aes-256-gcm -p -in enc.txt -out dec.txt The program executes but I get a bad decrypt message. However, when I open dec.txt, it is the same as the original file payload.txt My guess is that the problem is in the padding, but I have not been able to eliminate the error message, even setting the -nopad option and padding manually. Can someone please explain to me why this might be happening? I am running openSSL 1.0.1f (6 Jan 14) on an Ubuntu 14.04 LTS VM with current patches. AES GCM is not supported by the 'enc' utility. More recent versions of OpenSSL throw out and error message if you try to use it from the command line. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] The evolution of the 'master' branch
On 07/02/2015 12:12, Michael Felt wrote: From someone who does NOT understand the in's and out's of what people (developers and users) have been using openSSL for. My first reaction is: have developers been using openSSL, or has it gone to abusing it? For the sake of argument - let's say just use as it has always been intended. Fundamentally, since its inception by EAY years ago, OpenSSL has provided two things to other software developers: A very popular implementation of the SSL protocols defined by Netscape/Mozilla/IETF, and an equally popular library of fundamental cryptographic building blocks such as large numbers and various types of encryption and decryption. My criticism of the OpenSSL changes in the future version 1.1.0 is that they are removing the most flexible building blocks from the part that is intended to be used. Many technologies - especially related to security - whether it be a big log through 'something', to skeleton keys', to digital keys, etc - we want to be able to trust our locks. When the lock technology is no longer trustworthy - whether it be packaging (which is what the discussion sounds like atm) or unrepairable concerns with the technology asis - we change our locks. 2014 saw some widely published problems with various SSL variants. Heartbleed was a programming error found *only* in the OpenSSL SSL code and did not affect the handful of competing SSL implementations (such as the NSS one by Mozilla and the STUNNEL one by Microsoft). Essentially, heartbleed allowed people to put a hook through the keyhole and steal the key from behind the locked door. Poodle was a new way to attack a known weakness in the old version 3.0 of the SSL protocol, affecting all implementations, combined with a weakness in how Web Browsers work around bad SSL libraries that refuse to even reply to requests for protocol version 3.1 (TLS 1.0). On top of that, it turned out that a few minor competing SSL implementations (not OpenSSL, NSS and STUNNEL) never implemented the TLS 1.0 protection against the known weakness, leading to a rumor that poodle affected all TLS 1.0 implementations, and not just the few broken ones. Not everyone changes locks at the same moment in time. urgency depends on need, i.e., what is at risk. I started following these discussions because I am concerned (remember I am not really interested in the inner workings. I just think my locks are broken and wondering if it is time to change to something that maybe can do less - but what it does, does it better than what I have now. Regardless of the choices made by openssl - people outside openssl have needs and are looking at alternatives. To someone like me it is obvious something must change - even if technically it is cosmetic - because (open)SSL is losing the trust of it's users. As a user - I need a alternative. And just as I stopped using telnet/ftp/rsh/etc- because I could not entrust the integrity of my systems when those doors were open - so are my concerns re: (open)SSL. In short, is SSL still secure? And, very simply, as an un-knowledgeable user - given the choice of a library that does something well - and that's it, versus something else that does that - but leaves room for 'experiments' - Not on my systems. Experiment in experiment-land. My two bits. On Fri, Feb 6, 2015 at 9:59 PM, Matt Caswell m...@openssl.org mailto:m...@openssl.org wrote: On 06/02/15 16:03, Jakob Bohm wrote: I believe you have made the mistake of discussing only amongst yourselves, thus gradually convincing each other of the righteousness of a flawed decision. ...and, Rich said in a previous email (in response to your comment): I fear that this is an indication that you will be killing off all the other non-EVP entrypoints in libcrypto Yes there is a good chance of that happening. I'd like to stress that there has been no decision. In fact we're not even close to a decision on that at the moment. Whilst this has certainly been discussed I don't believe we are near to a consensus view at the moment. So whilst there is a good chance of that happeningthere's also a very good chance of it not. It is still under discussion. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] DTLS Handshake issue (openssl-1.0.1e-dtls-ecc-ext.patch) leads to process crash
Bug report OS: Linux OpenSSL Version: 1.0.1e-30 While doing DTLS testing with openssl-1.0.1e-30 Version and patches for RT3327, RT3470 and RT3483 on top of that, we are facing an issue where our process is crashing during the duration run of 24 hours. Use Case: *There are 125 DTLS Server Connections and 125 DTLS Client Connections. *Connection Attempts towards Server connections are also being made every 1 second. *Client Connections are initiating connection attempts every 1 second . *SSL Handshake is made to fail so that connection attempts continues and there are no crashes observed. During the above duration run, process is always crashing at the below location always. #4 signal handler called #5 0x7f61e97188e9 in sha1_block_data_order_ssse3 () from /usr/lib64/libcrypto.so.10 #6 0xad89a0d6776026f6 in ?? () #7 0xf9e71fd74025dad7 in ?? () #8 0x2243d5d8167d7997 in ?? () #9 0x8bbb75d9b4efd5d8 in ?? () #10 0xea9689da4d4ac2cb in ?? () #11 0x7067bc5f5034983b in ?? () #12 0xe19f5aa4a5679ed0 in ?? () #13 0x8ecbf7e83d1d8ccd in ?? () #14 0x7f61e9a827ce in state () from /usr/lib64/libcrypto.so.10 #15 0xbc803cd0 in ?? () #16 0x0011 in ?? () #17 0x7f61e9715de7 in SHA1_Update () from /usr/lib64/libcrypto.so.10 #18 0x7f61e97899fd in ssleay_rand_add () from /usr/lib64/libcrypto.so.10 #19 0x7f61e9ed92f9 in dtls1_accept () from /usr/lib64/libssl.so.10 When we tested with openssl-1.0.1e-16 Version and patches for RT3327, RT3470 and RT3483 on top of that, the use case works fine. On investigation, we found that there are 11 patches added between openssl-1.0.1e-30 and openssl-1.0.1e-16 version out of which following 3 patches are related to DTLS. openssl-1.0.1e-dtls-ecc-ext. patch openssl-1.0.1e-cve-2014-3513. patch openssl-1.0.1e-fallback-scsv.patch We have narrowed down that when we use openssl-1.0.1e-30 Version with the openssl-1.0.1e-dtls-ecc-ext.patch and patches for RT3327, RT3470 and RT3483 on top of that, process crashes with the above abterm during the duration run of 24 hours. When we excluded the openssl-1.0.1e-dtls-ecc-ext.patch from openssl-1.0.1e-30 Version, we didn't see an abterm during the duration run of 24 hours. Therefore, it seems that the openssl-1.0.1e-dtls-ecc-ext.patch is causing the abterm in the duration run. Please let us know if there could be issues with the openssl-1.0.1e-dtls-ecc-ext.patch? Regards, Sanchit Arora ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to construct certificate chain
I am using 1.0.2 stable release and add below code but it still get Equifax but browser get GeoTrust Global CA X509_VERIFY_PARAM *param; param = X509_VERIFY_PARAM_new(); X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_TRUSTED_FIRST); SSL_CTX_set1_param(ctx, param); X509_VERIFY_PARAM_free(param); On Mon, Nov 17, 2014 at 3:43 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Mon, Nov 17, 2014 at 03:13:22PM +0800, Jerry OELoo wrote: When I construct google's (www.google.com) certificate chain, it is different with browser's [openssl API] www.google.com - Google Internet Authority G2 - GeoTrust Global CA - Equifax Secure Certificate Authority This is what Google sends on the wire. [IE/Chrome] www.google.com - Google Internet Authority G2 - GeoTrust Global CA The browsers short-cicuit the chain, by finding an alternative trusted issuer for G2 It seems openssl use one certificate path with bridge cert but browsers use another certificate path, and in answer, it said OpenSSL, which curl uses, is not, or at least not yet; thus you must tell curl to give OpenSSL the Equifax root. (The OpenSSL 1.0.2 release, currently in beta, is announced to have enhancements in the area of cert chain validation, which I haven't looked at in detail yet., Commit 9d2006d8 (1.0.2 branch) implements a new X509_V_FLAG_TRUSTED_FIRST flag which should give similar (to the browsers) results if set in the X509_STORE_CTX used to validate the chain via: X509_VERIFY_PARAM_set_flags() and SSL_CTX_set1_param() see apps/apps.c and apps/s_client.c So is there any way that openssl 1.0.1j can solve this and construct same certificate path with browsers did? No, but it is far from clear why this is a problem. Google sends a chain signed by Equifax. So OpenSSL builds a chain with that. When Google stops sending the Equifax cert, OpenSSL will use the GeoTrust root CA if that's configured. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Rejoice,I Desire! ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to load local certificate folder on windows
On 06/02/2015 20:19, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Dave Thompson Sent: Friday, February 06, 2015 12:04 * Windows beginning AIR XP or maybe NT does support links on NTFS, but they're not easy to use and not well known, and I think I saw a recent bug report that they don't even work for OpenSSL, at least sometimes. In modern versions of Windows, NTFS supports three sorts of link-like objects: file symbolic links, directory symbolic links, and junctions, all of which are types of reparse points. Older versions of NTFS only support junctions. These can be created with the mklink command. Prior to Vista, there was no command in the base OS for this purpose, and you needed something like linkd from the Windows Server Resource Kit to manipulate links. Actually, there is a 4th and 5th form of NTFS native symbolic links: POSIX subsystem symbolic links, which have all the expected semantics but may not work with Win32 programs such as OpenSSL; and DFS junctions which have special semantics for the SMB/CIFS file sharing protocol. I just did a bit of testing with openssl.exe from OpenSSL 1.0.1k. It appears to work correctly with all three. Windows also supports shortcuts, but those are a Windows Explorer artifact. They're just files that have a particular extension and particular sort of contents. OpenSSL doesn't support them, but then neither do most programs. Shortcuts were invented for Windows 95 to overcome some of the limitations of the FAT32 filesystem. They're rubbish. Actually, shortcuts are really desktop/start menu entries, which store a command line, startup directory, menu icon and launch options. They work like the .desktop files in modern Linux desktop environments and should never have been confused with symbolic links. They were created as a more flexible replacement for the Windows 3.x program manager icon group files. And Cygwin provides both hard and symbolic UNIX-style links for NTFS. Hard links can only be to files. I'm not sure how Cygwin implements them, but they seem to work fine with OpenSSL. All versions of NTFS support hard links natively, though there is no command in the base OS to create them, and prior to Windows 2000, they could only be created via an undocumented API and/or by using the POSIX subsystem (which did include a working ln command though). When you run chkdsk (fsck) on an NTFS file system, you will see inodes referred to as Files in the Master File Table and directories as Indexes. Cygwin supports multiple implementations of symbolic links; see https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks. Default symbolic links are ordinary files recognized by the Cygwin library as special, so they aren't handled by (non-Cygwin) OpenSSL. Shortcut-style symlinks are shortcuts, so per above they do not work. Native symlinks are Windows symlinks and should work fine with OpenSSL. The native implementation can be selected by setting the CYGWIN environment variable appropriately, so (contrary to recent messages on the list) there's no reason to rewrite c_rehash for use on Windows. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] AES-GCM failing from Command Line Interface
Hello, I am trying to encrypt a short message using AES-256-GCM as mentioned in the subject. My command is: openssl enc -aes-256-gcm -p -in payload.txt -out enc.txt I get prompted for password as expected. The encryption goes well, and then I proceed to decrypt using: openssl enc -d -aes-256-gcm -p -in enc.txt -out dec.txt The program executes but I get a bad decrypt message. However, when I open dec.txt, it is the same as the original file payload.txt My guess is that the problem is in the padding, but I have not been able to eliminate the error message, even setting the -nopad option and padding manually. Can someone please explain to me why this might be happening? I am running openSSL 1.0.1f (6 Jan 14) on an Ubuntu 14.04 LTS VM with current patches. Thanks in advance for your help. Sent from my mobile ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] ui_openssl.c is assuming that current console is ECHO(termios) enabled
Hi,
OpenSSL, to be specific, ui_openssl.c, in my opinion, is assuming that
the current console before Enter PEM pass phrase prompt being
carried out is set with ECHO on (termios).
After using that prompt to get a pass phrase, applications using stdin
with ECHO off such as in the case of pseudo-terminals (pty) will
display any character twice when its key was pressed instead of only
once.
One example is text-mode pty IRC client irssi 0.8.15, using
self-signed certificate login protected with a pass phrase, utilizing
the Enter PEM pass phrase prompt.
crypto/ui/ui_openssl.c
static int noecho_console(UI *ui)
{
#ifdef TTY_FLAGS
memcpy((tty_new),(tty_orig),sizeof(tty_orig));
tty_new.TTY_FLAGS = ~ECHO;
#endif
...
}
static int echo_console(UI *ui)
{
#if defined(TTY_set) !defined(OPENSSL_SYS_VMS)
memcpy((tty_new),(tty_orig),sizeof(tty_orig));
tty_new.TTY_FLAGS |= ECHO;
#endif
...
}
Of course, a guard can be put into client applications to back up and
restore the attributes. But should this behaviour in openssl be
allowed ? Or am I looking into the wrong place ?
I wonder why ECHO is added to the current terminal attributes after
the prompt is finished. My strace log found that c_lflags (local
modes) before the prompt is 0x8a31 and 0x8a39 afterwards.
OS : Slackware 14.1
Regards,
Khang.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] DTLS Handshake issue (openssl-1.0.1e-dtls-ecc-ext.patch) leads to process crash
On 09/02/15 20:17, sanchit arora wrote: Bug report OS: Linux Which distro? OpenSSL Version: 1.0.1e-30 That is not an OpenSSL version - that is an OS vendor specific version based on OpenSSL 1.0.1e While doing DTLS testing with openssl-1.0.1e-30 Version and patches for RT3327, RT3470 and RT3483 on top of that, we are facing an issue where our process is crashing during the duration run of 24 hours. Use Case: *There are 125 DTLS Server Connections and 125 DTLS Client Connections. *Connection Attempts towards Server connections are also being made every 1 second. *Client Connections are initiating connection attempts every 1 second . *SSL Handshake is made to fail so that connection attempts continues and there are no crashes observed. During the above duration run, process is always crashing at the below location always. #4 signal handler called #5 0x7f61e97188e9 in sha1_block_data_order_ssse3 () from /usr/lib64/libcrypto.so.10 #6 0xad89a0d6776026f6 in ?? () #7 0xf9e71fd74025dad7 in ?? () #8 0x2243d5d8167d7997 in ?? () #9 0x8bbb75d9b4efd5d8 in ?? () #10 0xea9689da4d4ac2cb in ?? () #11 0x7067bc5f5034983b in ?? () #12 0xe19f5aa4a5679ed0 in ?? () #13 0x8ecbf7e83d1d8ccd in ?? () #14 0x7f61e9a827ce in state () from /usr/lib64/libcrypto.so.10 #15 0xbc803cd0 in ?? () #16 0x0011 in ?? () #17 0x7f61e9715de7 in SHA1_Update () from /usr/lib64/libcrypto.so.10 #18 0x7f61e97899fd in ssleay_rand_add () from /usr/lib64/libcrypto.so.10 #19 0x7f61e9ed92f9 in dtls1_accept () from /usr/lib64/libssl.so.10 There is insufficient information in the above to diagnose the problem. We would need a build with full debugging symbols. When we tested with openssl-1.0.1e-16 Version and patches for RT3327, RT3470 and RT3483 on top of that, the use case works fine. On investigation, we found that there are 11 patches added between openssl-1.0.1e-30 and openssl-1.0.1e-16 version out of which following 3 patches are related to DTLS. openssl-1.0.1e-dtls-ecc-ext. patch openssl-1.0.1e-cve-2014-3513. patch openssl-1.0.1e-fallback-scsv.patch We have narrowed down that when we use openssl-1.0.1e-30 Version with the openssl-1.0.1e-dtls-ecc-ext.patch and patches for RT3327, RT3470 and RT3483 on top of that, process crashes with the above abterm during the duration run of 24 hours. When we excluded the openssl-1.0.1e-dtls-ecc-ext.patch from openssl-1.0.1e-30 Version, we didn't see an abterm during the duration run of 24 hours. Therefore, it seems that the openssl-1.0.1e-dtls-ecc-ext.patch is causing the abterm in the duration run. Please let us know if there could be issues with the openssl-1.0.1e-dtls-ecc-ext.patch? All of the above are vendor specific patches (probably based on original OpenSSL commits). However I don't know from the name what dtls-ecc-ext is referring to. You would need to address your specific question to your vendor. Is it possible that you can run the latest 1.0.1 version of standard OpenSSL (i.e. OpenSSL 1.0.1l)? There have been some significant DTLS related fixes that have been applied in recent versions. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
