Re: Compiling for RISC-V

[Kristin Barber]

Hi Richard,

You're right, in fact, some newer releases of Debian even seem to ship with 
Configuration files having entries for riscv platforms explicitly!

I've realized that the problems I was seeing were more nuanced than I 
originally thought.  The RISC-V toolchain actually has two flavors: one that is 
newlib-based and one that is linux-gnu-based.  I am using the newlib toolchain, 
its an embedded environment, where in fact I don't expect to have any OS 
support at all.  The errors I was seeing were the result of some extra flags 
needed to allow newlib to play nicely with the OpenSSL build, such as nostdlib. 
 However, of course there are still errors associated with the syscalls that 
aren't implemented in this case, but I believe that is now the only remaining 
issue.

This brings me to another point, which may be outside the scope of this thread 
and please let me know if I should open another one to address this: for 
constrained environments without an OS, is there a best practice for compiling 
OpenSSL? I actually don't even need *all* of OpenSSL, just the crypto, even 
more specifically, the RSA encrypt/decrypt.  For syscall functionality, do 
folks typically pull them from open-source kernels as an easy way to get 
up-and-running?  Any kind of insights on this would be great.

Thanks,
Kristin

On 3/9/20, 9:30 PM, "openssl-users on behalf of Richard Levitte" 
 wrote:

Hi,

when you mentioned cross compiling, that got me a bit more curious, so
I went looking, and noticed that Debian [sid] (which is what I run on
my laptop) has all the cross compiling tools I needed (see
https://wiki.debian.org/RISC-V#Cross_compilation), so I installed
them, and then tried this in my checkout of OpenSSL's master branch:

./Configure linux-generic64 no-asm no-threads \
--cross-compile-prefix=riscv64-linux-gnu-

Running 'make' was a breeze, it went through flawlessly.

I haven't done much further tests, though.

Cheers,
Richard

On Mon, 09 Mar 2020 20:23:09 +0100,
Kristin Barber wrote:
> 
> 
> I did also try configuring for "no-asm", but there still seemed to be 
architecture-specific issues
> based on which files the errors were coming from.  I should probably also 
mention that I am
> attempting to cross-compile for RV64 from an x86 machine.
> 
> On Mon, Mar 9, 2020 at 3:12 PM Scott Neugroschl  wrote:
> 
>  
>
> Is the “no-asm” configuration option still supported?
>
>  
>
> From: openssl-users  On Behalf Of 
Kristin Barber
> Sent: Monday, March 9, 2020 12:03 PM
> To: Richard Levitte 
> Cc: openssl-users@openssl.org
> Subject: Re: Compiling for RISC-V
>
>  
>
> Hi Richard, thanks for the reply. It was helpful.
>
>  
>
> You are correct, I was able to find a configuration that worked by 
passing the RISC-V compiler
> via "make variable" assignment, along with some relevant options.  
Things start compiling, but
> the build fails on what seems to be architecture-specific assembly 
files which are selected
> based on which "platform" has been configured.  It did not seem to me 
that there were RISC-V
> assembly-specific files as an option here, and based on your reply, I 
think that is indeed the
> issue.  Am I understanding this correctly?
>
>  
>
> Thanks,
>
>  
>
> Kristin
>
>  
>
> On Mon, Mar 9, 2020 at 3:03 AM Richard Levitte  
wrote:
>
> On Mon, 09 Mar 2020 05:18:17 +0100,
> Kristin Barber wrote:
> > I've looked at the INSTALL docs, and it doesn't seem that 
RISC-V processors are
> supported
> > currently as a platform. Is this correct?
>
> That is correct.  No one has implemented that support yet.
>
> > Is there a branch which enables configuring for a RISC-V 
machine that hasn't yet made it
> into a
> > stable release?  
>
> Not that I know of.  Although, this same question has also been 
raised
> on github (I forget the issue number).
>
> > Any advice on where to look for information or changes to the 
build process in order to
> compile
> > for RISC-V?
>
> The first thing to attempt is a generic build with no assembler.
> There are some really simply config targets that could be a first
> step, one of:
>
> ./Configure cc
>
> ./Configure gcc
>
> A (pretty big) step up from that, at least if Linux is your 
target,
> would be one of 

some testers needed for PHP CMS calls

[Eliot Lear]

Hi everyone,

If anyone is interested, I have attempted to port the OpenSSL CMS
routines into PHP.  The code is available in a PR at
https://github.com/php/php-src/pull/5251.  Comments/reviews most welcome.

Eliot





signature.asc
Description: OpenPGP digital signature

Re: Question about handshake error

[Sergio NNX]

It seems to work fine here!


[cid:e41cb622-8559-442b-9b65-76043c2c4b27]


[cid:a3ae8ac2-646c-41c8-9842-4f9bde0aaf71]





From: openssl-users  on behalf of Matt 
Caswell 
Sent: Wednesday, 11 March 2020 4:25 AM
To: Niki Dinsey ; openssl-users@openssl.org 

Subject: Re: Question about handshake error



On 10/03/2020 17:05, Niki Dinsey wrote:
> Hi there, I have an issue I can't seem to work out the answer to.
>
> Server: thankqcrm.accessacloud.com 
>
> root@willis:~# openssl version
> OpenSSL 1.1.1d  10 Sep 2019
> root@willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443
> 

Running the exact same openssl version from my machine, and using the
exact same s_client options as you, I get a successful connection.

Some possibilities of what might be going wrong:

1) Is it possible there is some middlebox betwen you and the target
server that is causing a problem for you on your network? Can you try
connecting from s_client from a machine outside your corporate network?

or

2) I have sometimes seen load balancers do strange things - where
different machines in the cluster are configured differently to each
other. This can mean different people see different results - or even if
you run the same test at different times you see different results. This
could explain why it works in 1.1.0 and not 1.1.1 (i.e. it actually is
equally broken - but sometimes you hit the "right" server, and sometimes
you hit the "wrong" server). You might want to try from a different
machine and see if the same thing happens, and/or repeat the tests
periodically (in the hope of hitting different servers in the cluster).

or

3) Possibly there is some local problem with your s_client build. Does
it work ok for other sites?


Matt


> CONNECTED(0004)
> 140151269360768:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
> handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 7 bytes and written 318 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> Early data was not sent
> Verify return code: 0 (ok)
> ---
>
> Works on OpenSSL 1.1.0:
>
> root@host:~# openssl version
> OpenSSL 1.1.0l  10 Sep 2019
> root@host:~# openssl s_client -connect thankqcrm.accessacloud.com:443
> 
> CONNECTED(0003)
> depth=2 C = US, O = DigiCert Inc, OU = 
> www.digicert.com
> , CN = DigiCert Global Root CA
> verify return:1
> depth=1 C = US, O = DigiCert Inc, OU = 
> www.digicert.com
> , CN = Thawte RSA CA 2018
> verify return:1
> depth=0 CN = *.accessacloud.com 
> verify return:1
> ---
> Certificate chain
>  0 s:/CN=*.accessacloud.com 
>i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte
>  RSA CA 2018
>  1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte
>  RSA CA 2018
>i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert
>  Global Root CA
>  2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert
>  Global Root CA
>i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert
>  Global Root CA
>  3 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert
>  Global Root CA
>i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert
>  Global Root CA
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> ...
> -END CERTIFICATE-
> subject=/CN=*.accessacloud.com 
> issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte
>  RSA CA 2018
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 4999 bytes and written 494 bytes
> Verification: OK
> ---
> New, TLSv1.2, Cipher is AES128-GCM-SHA256
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: AES128-GCM-SHA256
> Session-ID:
> 05326CD4A0D128684EA530A59504BA8D02E99746AC2E40D0DA8B9B0E18F20CF0
> Session-ID-ctx:
> Master-Key:
> B423C27867FFB6A021458D860CC8A5A6D947628A8216B5F8DD8D1CF3058545398185B94F772B3A816A15D1442FFF1822
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> TLS session ticket lifetime hint: 14400 (seconds)
> TLS session ticket:
>  - e5 7b cf ea bc 3d 6b 9a-59 ec 40 63 01 19 52 6c
> .{...=k...@c..rl
> 0010 - 72 

Re: Question about handshake error

[Matt Caswell]

On 10/03/2020 17:05, Niki Dinsey wrote:
> Hi there, I have an issue I can't seem to work out the answer to.
> 
> Server: thankqcrm.accessacloud.com 
> 
> root@willis:~# openssl version
> OpenSSL 1.1.1d  10 Sep 2019
> root@willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443
> 

Running the exact same openssl version from my machine, and using the
exact same s_client options as you, I get a successful connection.

Some possibilities of what might be going wrong:

1) Is it possible there is some middlebox betwen you and the target
server that is causing a problem for you on your network? Can you try
connecting from s_client from a machine outside your corporate network?

or

2) I have sometimes seen load balancers do strange things - where
different machines in the cluster are configured differently to each
other. This can mean different people see different results - or even if
you run the same test at different times you see different results. This
could explain why it works in 1.1.0 and not 1.1.1 (i.e. it actually is
equally broken - but sometimes you hit the "right" server, and sometimes
you hit the "wrong" server). You might want to try from a different
machine and see if the same thing happens, and/or repeat the tests
periodically (in the hope of hitting different servers in the cluster).

or

3) Possibly there is some local problem with your s_client build. Does
it work ok for other sites?


Matt


> CONNECTED(0004)
> 140151269360768:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
> handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 7 bytes and written 318 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> Early data was not sent
> Verify return code: 0 (ok)
> ---
> 
> Works on OpenSSL 1.1.0:
> 
> root@host:~# openssl version
> OpenSSL 1.1.0l  10 Sep 2019
> root@host:~# openssl s_client -connect thankqcrm.accessacloud.com:443
> 
> CONNECTED(0003)
> depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com
> , CN = DigiCert Global Root CA
> verify return:1
> depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com
> , CN = Thawte RSA CA 2018
> verify return:1
> depth=0 CN = *.accessacloud.com 
> verify return:1
> ---
> Certificate chain
>  0 s:/CN=*.accessacloud.com 
>    i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte
>  RSA CA 2018
>  1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte
>  RSA CA 2018
>    i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert
>  Global Root CA
>  2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert
>  Global Root CA
>    i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert
>  Global Root CA
>  3 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert
>  Global Root CA
>    i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert
>  Global Root CA
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> ...
> -END CERTIFICATE-
> subject=/CN=*.accessacloud.com 
> issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte
>  RSA CA 2018
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 4999 bytes and written 494 bytes
> Verification: OK
> ---
> New, TLSv1.2, Cipher is AES128-GCM-SHA256
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : AES128-GCM-SHA256
>     Session-ID:
> 05326CD4A0D128684EA530A59504BA8D02E99746AC2E40D0DA8B9B0E18F20CF0
>     Session-ID-ctx:
>     Master-Key:
> B423C27867FFB6A021458D860CC8A5A6D947628A8216B5F8DD8D1CF3058545398185B94F772B3A816A15D1442FFF1822
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     TLS session ticket lifetime hint: 14400 (seconds)
>     TLS session ticket:
>      - e5 7b cf ea bc 3d 6b 9a-59 ec 40 63 01 19 52 6c  
> .{...=k...@c..rl
>     0010 - 72 c4 34 f0 a3 ff 37 f4-58 b1 9a bb 84 fc 94 36  
> r.4...7.X..6
>     0020 - 16 8e 39 04 94 e2 fd ae-0f 05 e7 6c 12 94 58 4a  
> ..9l..XJ
>     0030 - 09 56 e5 bd 67 d7 e7 17-d4 a8 03 ba 6e 05 be b6  
> .V..g...n...
>     0040 - ce 5d 9a ee 81 73 97 c8-ff 9c be 6b 8f 37 cb bf  
> .]...s.k.7..
>     0050 - 44 76 93 83 95 58 6d b8-63 f6 ba 4d 55 22 d2 14  
> 

Question about handshake error

[Niki Dinsey]

Hi there, I have an issue I can't seem to work out the answer to.

Server: thankqcrm.accessacloud.com

root@willis:~# openssl version
OpenSSL 1.1.1d  10 Sep 2019
root@willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443
CONNECTED(0004)
140151269360768:error:14094410:SSL routines:ssl3_read_bytes:sslv3
alert handshake
failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 318 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Works on OpenSSL 1.1.0:

root@host:~# openssl version
OpenSSL 1.1.0l  10 Sep 2019
root@host:~# openssl s_client -connect thankqcrm.accessacloud.com:443
CONNECTED(0003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA
2018
verify return:1
depth=0 CN = *.accessacloud.com
verify return:1
---
Certificate chain
 0 s:/CN=*.accessacloud.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
 2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
 3 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-BEGIN CERTIFICATE-
...
-END CERTIFICATE-
subject=/CN=*.accessacloud.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
---
No client certificate CA names sent
---
SSL handshake has read 4999 bytes and written 494 bytes
Verification: OK
---
New, TLSv1.2, Cipher is AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: AES128-GCM-SHA256
Session-ID:
05326CD4A0D128684EA530A59504BA8D02E99746AC2E40D0DA8B9B0E18F20CF0
Session-ID-ctx:
Master-Key:
B423C27867FFB6A021458D860CC8A5A6D947628A8216B5F8DD8D1CF3058545398185B94F772B3A816A15D1442FFF1822
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 14400 (seconds)
TLS session ticket:
 - e5 7b cf ea bc 3d 6b 9a-59 ec 40 63 01 19 52 6c   .{...=k.Y.@c.
.Rl
0010 - 72 c4 34 f0 a3 ff 37 f4-58 b1 9a bb 84 fc 94 36
r.4...7.X..6
0020 - 16 8e 39 04 94 e2 fd ae-0f 05 e7 6c 12 94 58 4a
..9l..XJ
0030 - 09 56 e5 bd 67 d7 e7 17-d4 a8 03 ba 6e 05 be b6
.V..g...n...
0040 - ce 5d 9a ee 81 73 97 c8-ff 9c be 6b 8f 37 cb bf
.]...s.k.7..
0050 - 44 76 93 83 95 58 6d b8-63 f6 ba 4d 55 22 d2 14
Dv...Xm.c..MU"..
0060 - 93 09 01 46 f0 fa f1 35-5a 80 0e ab a4 ca 9e c8
...F...5Z...
0070 - ed 8f c8 3c 89 e8 91 b3-0e 41 a9 e4 3f 79 f6 63
...<.A..?y.c
0080 - e2 62 91 c9 2f 8c 5a dd-b0 a1 55 b3 86 35 62 5a
.b../.Z...U..5bZ
0090 - af c2 9a 8a 35 7a 46 3b-3c 2e 24 0d 45 69 96 fc
5zF;<.$.Ei..

Start Time: 1583859230
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---


Works using 1.1.1d if I pass in -tls1_1

root@willis:~# openssl version
OpenSSL 1.1.1d  10 Sep 2019
root@willis:~# openssl s_client -connect thankqcrm.accessacloud.com:443
-tls1_1
CONNECTED(0004)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert
Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA
2018
verify return:1
depth=0 CN = *.accessacloud.com
verify return:1
---
Certificate chain
 0 s:CN = *.accessacloud.com
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA
2018
 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA
2018
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global
Root CA
 2 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global
Root CA
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global
Root CA
 3 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global
Root CA
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global
Root CA
---
Server certificate
-BEGIN CERTIFICATE-
...
-END CERTIFICATE-
subject=CN = *.accessacloud.com

issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte RSA CA
2018

---
No client certificate CA names sent
---
SSL handshake has read 5059 bytes and written 481 bytes
Verification: OK
---
New, SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE

Negotiated cipher per proto (matching cipher in list missing). No further cipher order check has been done as order is determined by the client

[Kaushal Shriyan]

Hi,

I have run the below tests

./testssl.sh gsmasslciphers.digitalapicraft.com
> ###
> testssl.sh   3.1dev from https://testssl.sh/dev/
> (e0c83b2 2020-02-24 14:21:28 -- )
>   This program is free software. Distribution and
>  modification under GPLv2 permitted.
>   USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
>Please file bugs @ https://testssl.sh/bugs/
> ###
>  Using "OpenSSL 1.0.2-chacha (1.0.2k-dev)" [~183 ciphers]
>  on Kaushals-MacBook-Pro:./bin/openssl.Darwin.x86_64
>  (built: "Feb 22 09:55:43 2019", platform: "darwin64-x86_64-cc")
>
>  Start 2020-03-10 21:50:25-->> 13.234.216.57:443 (
> gsmasslciphers.digitalapicraft.com) <<--
>  rDNS (13.234.216.57):   --
>  Service detected:   HTTP
>
>  Testing protocols via sockets except NPN+ALPN
>  SSLv2  not offered (OK)
>  SSLv3  not offered (OK)
>  TLS 1  not offered
>  TLS 1.1not offered
>  TLS 1.2offered (OK)
>  TLS 1.3not offered and downgraded to a weaker protocol
>  NPN/SPDY   h2, http/1.1 (advertised)
>  ALPN/HTTP2 h2, http/1.1 (offered)
>  Testing cipher categories
>  NULL ciphers (no encryption)  not offered (OK)
>  Anonymous NULL Ciphers (no authentication)not offered (OK)
>  Export ciphers (w/o ADH+NULL) not offered (OK)
>  LOW: 64 Bit + DES, RC[2,4] (w/o export)   not offered (OK)
>  Triple DES Ciphers / IDEA not offered
>  Obsolete: SEED + 128+256 Bit CBC cipher   not offered
>  Strong encryption (AEAD ciphers)  offered (OK)
>
>  Testing robust (perfect) forward secrecy, (P)FS -- omitting Null
> Authentication/Encryption, 3DES, RC4
>  PFS is offered (OK)  ECDHE-RSA-AES256-GCM-SHA384
> ECDHE-RSA-AES128-GCM-SHA256
>  Elliptic curves offered: secp256k1 prime256v1 secp384r1 secp521r1
>
>  Testing server preferences
>  Has server cipher order? no (NOT ok)
>  Negotiated protocol  TLSv1.2
>  Negotiated cipherECDHE-RSA-AES128-GCM-SHA256, 521 bit ECDH
> (P-521) -- inconclusive test, matching cipher in list missing, better see
> below
>  Negotiated cipher per proto  (matching cipher in list missing)
>  ECDHE-RSA-AES256-GCM-SHA384:   TLSv1.2
>  No further cipher order check has been done as order is determined by the
> client
>
>  Testing server defaults (Server Hello)
>  TLS extensions (standard)"server name/#0" "renegotiation info/#65281"
> "EC point formats/#11" "session ticket/#35" "heartbeat/#15" "next
> protocol/#13172" "application layer protocol negotiation/#16"
>  Session Ticket RFC 5077 hint 86400 seconds, session tickets keys seems to
> be rotated < daily
>  SSL Session ID support   yes
>  Session Resumption   Tickets: yes, ID: yes
>  TLS clock skew   Random values, no fingerprinting possible
>  Signature Algorithm  SHA256 with RSA
>  Server key size  RSA 2048 bits
>  Server key usage Digital Signature, Key Encipherment
>  Server extended key usageTLS Web Server Authentication, TLS Web
> Client Authentication
>  Serial / Fingerprints03C871BF68E569B4330E4AFCFA7752AAB5D7 / SHA1
> 8874D965CB96F4A4B8B4CCAE149B6F1999399BF8
>   SHA256
> BB56659442E2ED18778F7BB210823F3A81DA88F3AF79D0EE2104CE82DBB03C65
>  Common Name (CN) gsmasslciphers.digitalapicraft.com
>  subjectAltName (SAN) gsmasslciphers.digitalapicraft.com
>  Issuer   Let's Encrypt Authority X3 (Let's Encrypt
> from US)
>  Trust (hostname) Ok via SAN (same w/o SNI)
>  Chain of trust   Ok
>  EV cert (experimental)   no
>  ETS/"eTLS", visibility info  not present
>  Certificate Validity (UTC)   89 >= 30 days (2020-03-10 09:40 -->
> 2020-06-08 09:40)
>  # of certificates provided   2
>  Certificate Revocation List  --
>  OCSP URI http://ocsp.int-x3.letsencrypt.org
>  OCSP staplingnot offered
>  OCSP must staple extension   --
>  DNS CAA RR (experimental)not offered
>  Certificate Transparency yes (certificate extension)
>
>  Testing HTTP header response @ "/"
>  HTTP Status Code 200 OK
>  HTTP clock skew  0 sec from localtime
>  Strict Transport Security730 days=63072000 s, just this domain
>  Public Key Pinning   --
>  Server bannernginx/1.16.1
>  Application banner   --
>  Cookie(s)(none issued at "/")
>  Security headers --
>  Reverse Proxy banner --
>
>  Testing vulnerabilities
>  Heartbleed (CVE-2014-0160)not vulnerable (OK), timed out
>  CCS (CVE-2014-0224)   not vulnerable (OK)
>  Ticketbleed (CVE-2016-9244), experiment.  not vulnerable (OK)
>  ROBOT Server does not support any
> cipher suites that use RSA key