[openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found?
(Forwarded to openssl-users) The subjectName of file4.pem matches the issuerName of file3.pem, the signature block in file3.pem, when verified with the public key of file4.pem, gives a correct signature for the tbsCertificate of file3.pem. But Openssl also (incorrectly, IMO) checks that file4.pem.SKI matches file3.pem.AKI, and refuses to go further (here, AKI doesn't match SKI). -- Erwann ABALEA Le 03/04/2015 03:10, Yuting Chen a écrit : I used OpenSSL to verify a certificate file (file3.pem) against another certificate file (file4.pem). OpenSSL reports that it cannot find the issuer of the cert in file3.pem; while when I displays file3.pem and file4.pem, it appears that the issuer of the cert in file3.pem is the same as the subject of the cert in file4.pem. Did I miss anything? ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] QNX cross-compiled openssl with fips
Ok, whith few modifications to fipsld++ i can now link to libcrypto.so and libcrypto.a and applications are working correctly, but mine problem still persists because if i would like to dlopen my shared library compiled with static libcrypto.a and i'll try to run fips mode from that library i get an error: 755413103 which, i have read, means that library has an incorect digest and verification has failed. Now i found that fips_premain_dso is used to generate/get this digest from library but it does not generate or even does not output anything and it does not matter if it is linux/QNX or whatever platform it is. Maybe i'm using it wrong but could anubody tell me how to use this fips_premain_dso? I'm using it like that: LD_LIBRARY_PATH=/path/to/where/my/lib/is fips_premain_dso mylib.so And that does not output anything. Dnia 2015-04-02, czw o godzinie 08:58 +0200, Piotr Łobacz pisze: Yeah i have tried with it and modified it. But mine problem is that i am cross-compiling. I have used incore to generate digest and it works with qcc and i386-pc-nto-qnx6.4.0-gcc. But with i386-pc-nto-qnx6.4.0-g++ and QCC which is for c++ it does not work it generates bad digest. What is a problem because i have to use a machine with qnx to run the compiled code to get the proper digest and than recompile with it, what actually works because i've tested it. Dnia 2015-04-02, czw o godzinie 02:34 -0400, Jeffrey Walton pisze: On Thu, Apr 2, 2015 at 2:19 AM, Piotr Łobacz piotr.lob...@radmor.com.pl wrote: Ok finally my app is working and compiled with c++ compiler but the problem persist because elf incore is bad for QNX apps compiled with g++ or QCC compiler. It generates bad digest. Even incore2 generates bad digest, and i dunno why that happens. Any suggestions? You might try fipsld++ (https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B). Its for handling C++ compilers. I'm not sure why the various symbols are not exported with extern C. I don't recall trying it with a cross compile, though. It may work, it may not work. Either way, it may give you some ideas. Jeff -- Piotr Łobacz Biuro Systemów i Oprogramowania RADMOR S.A. tel. (58) 6996 929 e-mail: piotr.lob...@radmor.com.pl www.radmor.com.pl RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia NIP: 586-010-21-39 REGON: 190432077 KRS: 074029 (Sąd Rejonowy Gdańsk-Północ w Gdańsku) Kapitał zakładowy wpłacony: 9 282 830 PLN ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] HTTP / HTTPS on same port
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Salz, Rich Sent: Friday, April 03, 2015 15:55 To: openssl-users@openssl.org Subject: Re: [openssl-users] HTTP / HTTPS on same port It is a hack. That's debatable. What's so sacred about separating traffic by port? Valid TLS traffic and valid plaintext HTTP traffic are distinguishable - there aren't any ambiguous cases. Most people do it the other way and look for a G or P as the first letter. Now *that* is a hack. And wrong, and broken. Looking at the first few bytes to see if they're 1) ASCII uppercase letters and 2) form the prefix of a valid HTTP command would be satisfactory. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] removing compression?
I am thinking about removing compression and would like to know what the community thinks. At a minimum, I am going to remove the ability to add compression at run-time. This was never really documented. Moving forward, if someone wants to add a new compression scheme they will need to modify the OpenSSL source. This means COMP_METHOD becomes an internal datatype. But on a larger scale, does anyone use TLS compression? It has certainly caused problems with HTTP (see http://en.wikipedia.org/wiki/CRIME). And the best practice these days is to do it at the application layer, and feed the compressed bytes down to TLS. If this will cause problems for you, please post on the list, ideally within the next week. Thanks. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] HTTP / HTTPS on same port
It is a hack. Most people do it the other way and look for a G or P as the first letter. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] updating list of server account password
Hello Mike, Don and Matt,
At the point I am at this list of servers in my script I would really need
someone with more experience to see if I even have the right scripting.
#!/usr/bin/perl
use strict;
use Expect;
my $timeout = 60;
my @servers = qw(
remotehost03
remotehost04
remotehost05
remotehost06
);
for my $server (@servers) {
# do your thing with $server
change_password($server);
}
sub change_password {
my $system = shift;
my $filename = /var/tmp/expect_script.log;
my $ssh = Expect-new('ssh amagana@' . $system);
$ssh-debug(1);
$ssh-expect ( $timeout,
[ qr/Password:/],
[ qr/Are you sure you want to continue connecting \(yes\/no\)?/]
);
if ($ssh-match() =~ m/Are you sure you want to continue connecting
\(yes\/no\)?/ ) {
$ssh-send(yes\r);
}
elsif ($ssh-match() =~ m/Password:/ ) {
$ssh-send(mypassword\n);
}
#$ssh-log_file($filename, 'w');
$ssh-expect(60, '$');
$ssh-send(su - root\n);
$ssh-expect(60, 'Password:');
$ssh-send(rootpassword\n);
$ssh-expect(60, '#');
$ssh-send(passwd amagana\n);
$ssh-expect(60, 'New Password:');
$ssh-send(mynewpassword\n);
$ssh-expect(60, 'Re-enter new Password:');
$ssh-send(mynewpassword\n);
$ssh-expect(60, '#');
$ssh-close();
Respectfully,
#!/usr/bin/perl
use strict;
use Expect;
my $timeout = 60;
my $filename = /var/tmp/expect_script.log;
my $ssh = Expect-new('ssh amagana@remotehost');
$ssh-debug(1);
$ssh-expect ( $timeout,
[ qr/Password:/],
[ qr/Are you sure you want to continue connecting \(yes\/no\)?/]
);
if ($ssh-match() =~ m/Are you sure you want to continue connecting
\(yes\/no\)?/ ) {
$ssh-send(yes\r);
}
elsif ($ssh-match() =~ m/Password:/ ) {
$ssh-send(mypassword\n);
}
#$ssh-log_file($filename, 'w');
$ssh-expect(60, '$');
$ssh-send(su - root\n);
$ssh-expect(60, 'Password:');
$ssh-send(rootpassword\n);
$ssh-expect(60, '#');
$ssh-send(passwd amagana\n);
$ssh-expect(60, 'New Password:');
$ssh-send(mynewpassword\n);
$ssh-expect(60, 'Re-enter new Password:');
$ssh-send(mynewpassword\n);
$ssh-expect(60, '#');
$ssh-close();
//SIGNED//
Andy Magaña
UNIX Systems Administrator
Diligent Contractor, 72nd Air Base Wing
Tinker Air Force Base, Oklahoma
Commercial: (405) 734-0341
-Original Message-
From: mike nicholas [mailto:xmikenichol...@gmail.com]
Sent: Wednesday, April 01, 2015 9:46 AM
To: MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT
Cc: ESRY JR., DON; Matt Zagrabelny; expectperl-disc...@lists.sourceforge.net
Subject: Re: [Expectperl-discuss] expect.pm not updating password
Try something like this:
my $exp = new Expect;
$exp-log_stdout(1);
$username = XX;
$exp-spawn( ssh -l ${username} ${ip} ) or die cannot spawn $command: $!
\n;
$exp-log_file(./${log_dir}/$ip\_info.log);
print \nspawning ssh connection to $ip on $time\n\n;
$exp-log_file-print( \nspawning ssh connection to $ip on $time\n\n );
$exp-expect(8,
[ 'connecting' = sub { $exp-send(yes \n); exp_continue; } ],
[ 'assword:' = sub { $exp-send($pw\n); exp_continue; } ],
[ '-re', ' ?$' = sub { break; }],
[ 'try again' = sub { die died from bad password.\n; }],
[ 'refused' = sub { die died from connection refused.\n; exp_continue; }
],
[ eof = sub { die died from eof.\n; }],
[ timeout = sub { $exp-hard_close(); }],
);
On Wed, Apr 1, 2015 at 9:24 AM, MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT
andreas.magana@us.af.mil wrote:
Now that I have a working script and thanks very much to you Matt and
Don,
I am trying to put in my script an if else because sometimes my script
will encounter this :
Are you sure you want to continue connecting (yes/no)?')
what I did create are some variables is this correct and may I see an
example if statement so that the script can make a decision and keep going?
use Expect;
my $knownhost = $ssh-expect(60, 'Are you sure you want to continue
connecting (yes/no)?');
my $answer = $ssh-send(yes\n);
my $filename = /var/tmp/expect_script.log;
//SIGNED//
Andy Magaña
UNIX Systems Administrator
Diligent Contractor, 72nd Air Base Wing
Tinker Air Force Base, Oklahoma
Commercial: (405) 734-0341 tel:%28405%29%20734-0341
-Original Message-
From: ESRY JR., DON [mailto:de3...@att.com]
Sent: Tuesday, March 31, 2015 4:16 PM
To: Matt Zagrabelny; MAGANA, ANDREAS S I CTR USAF AFMC 72 ABW/SCOOT
Cc: expectperl-disc...@lists.sourceforge.net
Subject: RE: [Expectperl-discuss] expect.pm not updating password
I think you will want a
Re: [openssl-users] HTTP / HTTPS on same port
On 03/04/15 20:48, Joris Van Remoortere wrote: Hello, I would like to ask your opinion and advice on accepting HTTP / HTTPS connections on the same port. I currently have a prototype that peeks at the first byte after accepting a new connection, and dispatches to the appropriate routines based on whether the first byte is 0x16 or not. This came from looking at the TLS handshake protocol (http://en.wikipedia.org/wiki/Transport_Layer_Security#Handshake_protocol) and testing different libraries. The motivation for this was to avoid the configuration nightmare of introducing a second port, both in our code, and for administrators (firewall rules, etc.). 1) Is it valid to assume that the 1st byte of the handshake protocol is a valid way to disambiguate the traffic? 2) Are there any corner cases I might be missing? There is a potential issue to consider if you were going to do it this way. All modern clients will send 0x16 as the first byte of their ClientHello. However this was not always the case, and you may encounter some legacy clients that do not do this (for example OpenSSL 0.9.8 doesn't). Historically it was common to send SSLv2 backward compatible ClientHellos - even if what is eventually negotiated is SSLv3 or above. OpenSSL 0.9.8 will happily negotiate TLS1.0 by sending a SSLv2 backward compatible ClientHello. Note this doesn't have anything to do with the support for SSLv2 itself. Even servers which have disabled SSLv2 (which is considered good practice), will usually accept this ClientHello format (OpenSSL 1.0.2 does). The first two bytes of the backward compatible format are the message length. The most significant bit of the first byte is always set, so this means you could conceivably receive anything from 0x80 or above, as well as 0x16 as your first byte. You may wish to look at how OpenSSL does protocol version detection to help you. See the function ssl23_get_client_hello() in ssl/s23_srvr.c of the OpenSSL 1.0.2 source code. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] HTTP / HTTPS on same port
Hello, I would like to ask your opinion and advice on accepting HTTP / HTTPS connections on the same port. I currently have a prototype that peeks at the first byte after accepting a new connection, and dispatches to the appropriate routines based on whether the first byte is 0x16 or not. This came from looking at the TLS handshake protocol ( http://en.wikipedia.org/wiki/Transport_Layer_Security#Handshake_protocol) and testing different libraries. The motivation for this was to avoid the configuration nightmare of introducing a second port, both in our code, and for administrators (firewall rules, etc.). 1) Is it valid to assume that the 1st byte of the handshake protocol is a valid way to disambiguate the traffic? 2) Are there any corner cases I might be missing? 3) Are there any security reasons for not doing this? Thanks for your advice, Joris ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] HTTP / HTTPS on same port
Hi,
I suggested one such implementation in mongoose opensource web server
You can check it in .
https://groups.google.com/forum/#!msg/mongoose-users/IAzYHF0do-I/INc_VmLAe6gJ
This is the function I added
let me know if it is useful.
static int CheckSSL(int nSocket)
{
/* taken from s23_svr.c int ssl23_get_client_hello(SSL *s) of openssl */
char szData [12] ;
int nRet = 0 ;
int n;
memset ( szData, 0, sizeof(szData));
n = recv ( nSocket, szData, 11, MSG_PEEK ) ;
if (n 2)
{
if((szData[0] 0x80) (szData[2] == 1)) // SSL2_MT_CLIENT_HELLO
{
// SSLv2
nRet = 1;
}
else if(n 9)
{
if ((szData[0] == 22 ) // SSL3_RT_HANDSHAKE
(szData[1] == 0x03) // SSL3_VERSION_MAJOR
(szData[5] == 1) // SSL3_MT_CLIENT_HELLO
((szData[3] == 0 szData[4] 5)
|| (szData[9] == szData[1])))
{
// SSLv3
nRet = 1;
}
}
}
return nRet;
}
On Sat, Apr 4, 2015 at 5:10 AM, James Cloos cl...@jhcloos.com wrote:
JR == Joris Van Remoortere jo...@mesosphere.io writes:
JR I would like to ask your opinion and advice on accepting HTTP / HTTPS
JR connections on the same port.
IPP support both w/ and w/o tls on port 631.
Cups handles it like this:
http://www.pwg.org/archives/ipp/2014/017906.html
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
___
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] Modulus field in text display of a certificate
On 04/04/2015 07:18, Jakob Bohm wrote: On 04/04/2015 04:07, Mabry Tyson wrote: I happened to notice what seems to be an output glitch in the textual output of a certificate. I received a copy of the QuoVadis Root CA 2 certificate as a file. When I examined the certificate via openssl x509 -text -in /tmp/QV.cer(using OpenSSL 1.0.1 14 Mar 2012 as installed in Ubuntu 14.04) I noticed an extra first zero byte of the Modulus was shown, as compared to the display of that certificate in Firefox. Certificate: Data: Version: 3 (0x2) Serial Number: 1289 (0x509) Signature Algorithm: sha1WithRSAEncryption Issuer: C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2 ... Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:9a:18:ca:4b:94:0d:00:2d:af:03:29:8a:f0:0f: ... 09:62:04:92:16:10:d8:9e:27:47:fb:3b:21:e3:f8: eb:1d:5b I believe there should be 4096/8 = 512 bytes in that modulus. There are 15 bytes shown per line. 512/15 = 34 with a remainder of 2. This output shows 513 bytes (34 lines plus a remainder of 3). This is a consequence of the ASN.1 DER/BER encoding rules: All INTEGER fields are signed, so when the most significant bit of a 2048 bit value is set, then it needs to be encoded and processed with an extra leading 0 byte. (And ditto for a 4096 bit value of cause) OpenSSL displays that leading 0 byte, while NSS (used by Firefox) apparently hides it. 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
Re: [openssl-users] HTTP / HTTPS on same port
JR == Joris Van Remoortere jo...@mesosphere.io writes: JR I would like to ask your opinion and advice on accepting HTTP / HTTPS JR connections on the same port. IPP support both w/ and w/o tls on port 631. Cups handles it like this: http://www.pwg.org/archives/ipp/2014/017906.html -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Modulus field in text display of a certificate
I happened to notice what seems to be an output glitch in the textual output of a certificate. I received a copy of the QuoVadis Root CA 2 certificate as a file. When I examined the certificate via openssl x509 -text -in /tmp/QV.cer(using OpenSSL 1.0.1 14 Mar 2012 as installed in Ubuntu 14.04) I noticed an extra first zero byte of the Modulus was shown, as compared to the display of that certificate in Firefox. Certificate: Data: Version: 3 (0x2) Serial Number: 1289 (0x509) Signature Algorithm: sha1WithRSAEncryption Issuer: C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2 ... Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:9a:18:ca:4b:94:0d:00:2d:af:03:29:8a:f0:0f: ... 09:62:04:92:16:10:d8:9e:27:47:fb:3b:21:e3:f8: eb:1d:5b I believe there should be 4096/8 = 512 bytes in that modulus. There are 15 bytes shown per line. 512/15 = 34 with a remainder of 2. This output shows 513 bytes (34 lines plus a remainder of 3). ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Modulus field in text display of a certificate
On 04/04/2015 04:07, Mabry Tyson wrote: I happened to notice what seems to be an output glitch in the textual output of a certificate. I received a copy of the QuoVadis Root CA 2 certificate as a file. When I examined the certificate via openssl x509 -text -in /tmp/QV.cer(using OpenSSL 1.0.1 14 Mar 2012 as installed in Ubuntu 14.04) I noticed an extra first zero byte of the Modulus was shown, as compared to the display of that certificate in Firefox. Certificate: Data: Version: 3 (0x2) Serial Number: 1289 (0x509) Signature Algorithm: sha1WithRSAEncryption Issuer: C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2 ... Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:9a:18:ca:4b:94:0d:00:2d:af:03:29:8a:f0:0f: ... 09:62:04:92:16:10:d8:9e:27:47:fb:3b:21:e3:f8: eb:1d:5b I believe there should be 4096/8 = 512 bytes in that modulus. There are 15 bytes shown per line. 512/15 = 34 with a remainder of 2. This output shows 513 bytes (34 lines plus a remainder of 3). This is a consequence of the ASN.1 DER/BER encoding rules: All INTEGER fields are signed, so when the most significant bit of a 2048 bit value is set, then it needs to be encoded and processed with an extra leading 0 byte. OpenSSL displays that leading 0 byte, while NSS (used by Firefox) apparently hides it. 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
Re: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found?
(top posting like the rest of the thread) What makes you think it is incorrect to check the Key Identifier (where present) before checking a signature against a key? What other reasonable purpose could the Key Identifier fields serve? On 03/04/2015 10:56, Erwann Abalea wrote: (Forwarded to openssl-users) The subjectName of file4.pem matches the issuerName of file3.pem, the signature block in file3.pem, when verified with the public key of file4.pem, gives a correct signature for the tbsCertificate of file3.pem. But Openssl also (incorrectly, IMO) checks that file4.pem.SKI matches file3.pem.AKI, and refuses to go further (here, AKI doesn't match SKI). Le 03/04/2015 03:10, Yuting Chen a écrit : I used OpenSSL to verify a certificate file (file3.pem) against another certificate file (file4.pem). OpenSSL reports that it cannot find the issuer of the cert in file3.pem; while when I displays file3.pem and file4.pem, it appears that the issuer of the cert in file3.pem is the same as the subject of the cert in file4.pem. Did I miss anything? P.S. Don't put your e-mail sig in the middle of the mail, it causes standards-compliant mail programs to cut off everything below it when replying (because everyting below the --space marker is, by definition, just the e-mail sig). 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
Re: [openssl-users] HTTP / HTTPS on same port
On 03/04/2015 22:12, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Salz, Rich
Sent: Friday, April 03, 2015 15:55
To: openssl-users@openssl.org
Subject: Re: [openssl-users] HTTP / HTTPS on same port
It is a hack.
That's debatable. What's so sacred about separating traffic by port? Valid TLS
traffic and valid plaintext HTTP traffic are distinguishable - there aren't any
ambiguous cases.
Most people do it the other way and look for a G or P as the first letter.
Now *that* is a hack. And wrong, and broken. Looking at the first few bytes to
see if they're 1) ASCII uppercase letters and 2) form the prefix of a valid
HTTP command would be satisfactory.
Actually, I would code any HTTP request parser to accept
lower case,even if I would code request generators to
issue the standard request keywordsin uppercase only
(as required by the spec). Basic Postel principle
in action, really.
Additionally the HTTP/1.1 spec (RFC2616) explicitly
allows future method namesto contain any US-ASCII
char except control chars (0x00..0x1F), space (0x20)
and the following separators: ()@,;:\\\/[]?={},
see RFC2616 section 5.1.1 which references the
definitions of token and CHAR in section 2.2.
In the updated HTTP/1.1 spec (RFC7230 et.seq.),
the equivalent rules are in RFC7230 section 3.1.1
with token and tchar defined in section 3.2.6 .
Another possibility for HTTP and HTTPS on the same
port is to implement RFC2817, which specifies a way
to use a HTTP request to switch a connection to HTTPS.
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
Re: [openssl-users] QNX cross-compiled openssl with fips
Ok i have finally managed to find what is the problem. The generated value of digest under linux had bad value. Now i have to correct incore file for QNX platform. Wish me luck or if anybody can help me with this i would be pleased. :) Dnia 2015-04-03, pią o godzinie 11:16 +0200, Piotr Łobacz pisze: Ok, whith few modifications to fipsld++ i can now link to libcrypto.so and libcrypto.a and applications are working correctly, but mine problem still persists because if i would like to dlopen my shared library compiled with static libcrypto.a and i'll try to run fips mode from that library i get an error: 755413103 which, i have read, means that library has an incorect digest and verification has failed. Now i found that fips_premain_dso is used to generate/get this digest from library but it does not generate or even does not output anything and it does not matter if it is linux/QNX or whatever platform it is. Maybe i'm using it wrong but could anubody tell me how to use this fips_premain_dso? I'm using it like that: LD_LIBRARY_PATH=/path/to/where/my/lib/is fips_premain_dso mylib.so And that does not output anything. Dnia 2015-04-02, czw o godzinie 08:58 +0200, Piotr Łobacz pisze: Yeah i have tried with it and modified it. But mine problem is that i am cross-compiling. I have used incore to generate digest and it works with qcc and i386-pc-nto-qnx6.4.0-gcc. But with i386-pc-nto-qnx6.4.0-g++ and QCC which is for c++ it does not work it generates bad digest. What is a problem because i have to use a machine with qnx to run the compiled code to get the proper digest and than recompile with it, what actually works because i've tested it. Dnia 2015-04-02, czw o godzinie 02:34 -0400, Jeffrey Walton pisze: On Thu, Apr 2, 2015 at 2:19 AM, Piotr Łobacz piotr.lob...@radmor.com.pl wrote: Ok finally my app is working and compiled with c++ compiler but the problem persist because elf incore is bad for QNX apps compiled with g++ or QCC compiler. It generates bad digest. Even incore2 generates bad digest, and i dunno why that happens. Any suggestions? You might try fipsld++ (https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B). Its for handling C++ compilers. I'm not sure why the various symbols are not exported with extern C. I don't recall trying it with a cross compile, though. It may work, it may not work. Either way, it may give you some ideas. Jeff -- Piotr Łobacz Biuro Systemów i Oprogramowania RADMOR S.A. tel. (58) 6996 929 e-mail: piotr.lob...@radmor.com.pl www.radmor.com.pl RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia NIP: 586-010-21-39 REGON: 190432077 KRS: 074029 (Sąd Rejonowy Gdańsk-Północ w Gdańsku) Kapitał zakładowy wpłacony: 9 282 830 PLN ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
