RE: Tunelling using OpenSSL.
> From: openssl-users On Behalf Of Jason > Long via openssl-users > Sent: Friday, 4 September, 2020 16:55 [Your message had a Reply-To header directing replies to your address rather than the list. If you did that deliberately, please don't. It's rude. You post here, you read here.] > Is it possible to tunnel a connection by OpenSSL? Yes, but probably not the way you mean. The OpenSSL project delivers a variety of artifacts, including: - a library (typically built as a collection of binaries, but notionally a single library for most purposes) that implements TLS, various cryptographic primitives, and related useful functions - a command-line utility (also named "openssl") which can be used for testing, manipulating cryptographic file formats, and other purposes - SDK components such as headers for developing applications that use OpenSSL - documentation What it does NOT include is an end-user application for general-purpose cryptography, similar to what OpenSSH provides. That's a rather different function. Of course you can tunnel anything through a TLS connection; you can tunnel anything through anything. Any channel that lets you convey unbounded information entropy, at whatever rate, can be used as a tunnel. You can tunnel IP traffic in DNS requests or carrier-pidgeon messages. But OpenSSL isn't going to do that for you. There are generic tunnel applications (e.g. stunnel) that use TLS and (I believe this is true of stunnel) specifically use OpenSSL as their TLS implementation, but those are separate projects. Now, you could play games with, say, NetCat and the openssl utility to create proxy TLS connections. For example, on the client side: 1. ncat -L ... | openssl s_client ... 2. connect plaintext client to the ncat port via loopback And on the server side: 1. openssl s_server ... | ncat ... 2. ncat connects to the server via loopback That sort of thing might even have its uses, for example as a simple exfiltration shroud. But it's not something you want to use under normal circumstances. > For example, use OpenSSL and a browser to encrypt browsing. Er ... you know browsers already do that, right? That's the quintessential TLS application. It might help if you explained what you're actually trying to accomplish, and why. -- Michael Wojcik
Tunelling using OpenSSL.
Hello,Is it possible to tunnel a connection by OpenSSL? For example, use OpenSSL and a browser to encrypt browsing. Thank you.
Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option
Viktor, Thank you for clarifying it. Yury From: openssl-users on behalf of Viktor Dukhovni Sent: Friday, September 4, 2020 12:10 PM To: openssl-users@openssl.org Subject: Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option On Fri, Sep 04, 2020 at 07:00:01PM +, Yury Mazin via openssl-users wrote: > Thank you Benjamin, > > According to OpenSSL , aNULL stands for no-authentication. Specifically, SSL 3.0 through TLS 1.2 ciphers in which the server and client exchange no certificates, and the TLS handshake consists largely of an unsigned anonymous ephemeral DH or ECDH key exchang. TLS 1.3 dropped support for anonymous DH and ECDH. Server certificates are *required. And the all-in-one ciphersuites of TLS <= 1.2, are replaced with separately negotiated components. As a result of which, in OpenSSL 1.1.1 and later, they are controlled via a different set of APIs and command-line options. Specifically, in your case, the "-ciphers aNULL" option only applies to TLS <= 1.2 > Does it mean that all 3 default protocols of TLS 1.3 offer no > authentication No. None of them "support no authentication" (which is not even strictly true, it is the protocol that does not support "no authentication", the TLS 1.3 ciphers are simply silent re certificate algorithm selection), but the "-cipher aNULL" is simply not used when TLS 1.3 is negotiated, so your question is makes incorrect assumptions to reach its tentative conclusions. -- Viktor.
Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option
On Fri, Sep 04, 2020 at 07:00:01PM +, Yury Mazin via openssl-users wrote: > Thank you Benjamin, > > According to OpenSSL , aNULL stands for no-authentication. Specifically, SSL 3.0 through TLS 1.2 ciphers in which the server and client exchange no certificates, and the TLS handshake consists largely of an unsigned anonymous ephemeral DH or ECDH key exchang. TLS 1.3 dropped support for anonymous DH and ECDH. Server certificates are *required. And the all-in-one ciphersuites of TLS <= 1.2, are replaced with separately negotiated components. As a result of which, in OpenSSL 1.1.1 and later, they are controlled via a different set of APIs and command-line options. Specifically, in your case, the "-ciphers aNULL" option only applies to TLS <= 1.2 > Does it mean that all 3 default protocols of TLS 1.3 offer no > authentication No. None of them "support no authentication" (which is not even strictly true, it is the protocol that does not support "no authentication", the TLS 1.3 ciphers are simply silent re certificate algorithm selection), but the "-cipher aNULL" is simply not used when TLS 1.3 is negotiated, so your question is makes incorrect assumptions to reach its tentative conclusions. -- Viktor.
Re: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option
Thank you Benjamin, According to OpenSSL , aNULL stands for no-authentication. NULL-ciphers that you mention would be part of eNULL group, that offer no encryption. Does it mean that all 3 default protocols of TLS 1.3 offer no authentication (because they are listed under command openssl ciphers -v -s aNULL TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD Thank you, Yury From: Benjamin Kaduk Sent: Thursday, September 3, 2020 5:12 PM To: Yury Mazin Cc: openssl-users@openssl.org Subject: [EXTERNAL] - Re: Question about TLS 1.3 and openssl -cipher aNULL option On Thu, Sep 03, 2020 at 11:45:28PM +, Yury Mazin via openssl-users wrote: > Hello, > > We have a server was originaly using OpenSSL 1.0.2h. > Server is configured to use SSL ciphers as following > ALL:!aNULL:!ADH:!EDH:!eNULL:!EXPORT > When openssl client tries to connect to this server with command > openssl s_client -connect localhost:8101-cipher aNULL > it fails, because any aNULL ciphers are not available per server > configuration. > We have now upgraded server to use OpenSSL 1.1.1f. > The current behavior is this: client can connect using the same command > openssl s_client -connect localhost:8101 -cipher aNULL > or > openssl s_client -tls1_3 -connect localhost:8101 -cipher aNULL > > while the same connect attempt using TLS1.2 protocol would still fail > > openssl s_client -tls1_2 -connect localhost:8001-cipher aNULL > > Would the fact that I can connect to the server using TLS 1.3 using the > following command (specifically, using -cipher aNULL, while server is > configured to exclude all aNULL cipher suites) considered a security > violation? > > openssl s_client -tls1_3 -connect localhost:8001 -cipher aNULL > > Also, if this a security violation, how this can be addressed in the server > configuration? > Lastly, if this is not a security violation, please explain. It is not a security violation, because you are using TLS 1.3 ciphers, and there are not any NULL-encryption TLS 1.3 ciphers. Configuration of TLS 1.3 ciphers and ciphers for previous versions of TLS are separate (since, at a protocol level, they serve different roles). See the documentation for s_client/s_server -ciphersuites for more information about TLS 1.3 ciphers. -Ben
Re: A question about the “localhost.key” and “localhost.crt” files.
The filenames themselves are insignificant. You can name them anything you want. The apache configuration file(s) contain key/value pairs where SSLCertificateFile specifies the path to the file containing your certificate and SSLCertificateKeyFile specifies the path to the file containing your private key. There is no requirement that these filenames match the name of your server. It sounds to me like you don't understand how certificates work. I suggest you read a certificate tutorial such as this one: http://www.steves-internet-guide.com/ssl-certificates-explained/ Once you understand how certificates work, I suggest reading the apache documentation available here: https://httpd.apache.org/docs/current/ and, specifically, the documentation for mod_ssl available here: https://httpd.apache.org/docs/current/mod/mod_ssl.html Regards, Tom.III On Fri, Sep 4, 2020 at 3:20 AM Jason Long via openssl-users < openssl-users@openssl.org> wrote: > Hello, > I think “localhost.crt” and “localhost.key” files using by Apache and they > are mandatory for get a HTTPS certificate. Some tools like "Certbot" need > them. > If these files deleted then how can I regenerate them? Is below command OK? > > # openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout > /etc/pki/tls/private/localhost.key -out /etc/ssl/certs/localhost.crt > > I found "/usr/libexec/httpd-ssl-gencerts" tool. Is it OK too? > > The "localhost" is the name of my server? If my server name in > "/etc/hosts" file is "my-example.net" then these files name must be > "my-example.net.key" and "my-example.net.crt" ? > > I'm thankful if anyone answer to my questions clearly. > > Thank you. >
A question about the “localhost.key” and “localhost.crt” files.
Hello, I think “localhost.crt” and “localhost.key” files using by Apache and they are mandatory for get a HTTPS certificate. Some tools like "Certbot" need them. If these files deleted then how can I regenerate them? Is below command OK? # openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/localhost.key -out /etc/ssl/certs/localhost.crt I found "/usr/libexec/httpd-ssl-gencerts" tool. Is it OK too? The "localhost" is the name of my server? If my server name in "/etc/hosts" file is "my-example.net" then these files name must be "my-example.net.key" and "my-example.net.crt" ? I'm thankful if anyone answer to my questions clearly. Thank you.
RE: Testing
As if amazon is the only provider you can host an mta. As I wrote before your laziness to find a proper provider solution, causes work at other providers. The only advantage that your type of customer has, is that your brains all work the same going for cheap and easy. So if I do block such a network, I block of useless traffic. I think amazon is expanding/changing strategy. Now they are even routing to dubious ip ranges. traceroute -n 185.187.119.175 traceroute to 185.187.119.175 (185.187.119.175), 30 hops max, 60 byte packets 4 92.63.170.153 0.516 ms 0.522 ms 0.534 ms 5 193.239.116.110 1.779 ms 1.154 ms 1.748 ms 6 52.93.112.28 4.971 ms 52.93.112.24 2.019 ms 52.93.112.28 4.677 ms 7 54.239.114.149 1.292 ms 54.239.114.103 1.629 ms 54.239.114.155 1.095 ms 8 * * * 9 * * * 185.187.119.2 mta119-2.msgfocus.com. 185.187.119.3 mta119-3.msgfocus.com. 185.187.119.4 mta119-4.msgfocus.com. 185.187.119.5 mta119-5.msgfocus.com. 185.187.119.6 mta119-6.msgfocus.com. 185.187.119.7 mta119-7.msgfocus.com. 185.187.119.8 mta119-8.msgfocus.com. 185.187.119.9 mta119-9.msgfocus.com. 185.187.119.10 mta119-10.msgfocus.com. 185.187.119.11 mta119-11.msgfocus.com. 185.187.119.12 mta119-12.msgfocus.com. 185.187.119.13 mta119-13.msgfocus.com. 185.187.119.14 mta119-14.msgfocus.com. 185.187.119.15 mta119-15.msgfocus.com. 185.187.119.16 mta119-16.msgfocus.com. 185.187.119.17 mta119-17.msgfocus.com. 185.187.119.18 mta119-18.msgfocus.com. 185.187.119.19 mta119-19.msgfocus.com. 185.187.119.20 mta119-20.msgfocus.com. 185.187.119.21 mta119-21.msgfocus.com. 185.187.119.22 mta119-22.msgfocus.com. 185.187.119.23 mta119-23.msgfocus.com. 185.187.119.24 mta119-24.msgfocus.com. 185.187.119.25 mta119-25.msgfocus.com. 185.187.119.26 mta119-26.msgfocus.com. 185.187.119.27 mta119-27.msgfocus.com. 185.187.119.28 mta119-28.msgfocus.com .. .. 185.187.119.223 mta119-223.msgfocus.com. 185.187.119.224 mta119-224.msgfocus.com. 185.187.119.225 mta119-225.msgfocus.com. 185.187.119.226 mta119-226.msgfocus.com. 185.187.119.227 mta119-227.msgfocus.com. 185.187.119.228 mta119-228.msgfocus.com. 185.187.119.229 mta119-229.msgfocus.com. 185.187.119.230 mta119-230.msgfocus.com. 185.187.119.231 mta119-231.msgfocus.com. 185.187.119.232 mta119-232.msgfocus.com. 185.187.119.233 mta119-233.msgfocus.com. 185.187.119.234 mta119-234.msgfocus.com. 185.187.119.235 mta119-235.msgfocus.com. 185.187.119.236 mta119-236.msgfocus.com. 185.187.119.237 mta119-237.msgfocus.com. 185.187.119.238 mta119-238.msgfocus.com. 185.187.119.239 mta119-239.msgfocus.com. 185.187.119.240 mta119-240.msgfocus.com. 185.187.119.241 mta119-241.msgfocus.com. 185.187.119.242 mta119-242.msgfocus.com. 185.187.119.243 mta119-243.msgfocus.com. 185.187.119.244 mta119-244.msgfocus.com. 185.187.119.245 mta119-245.msgfocus.com. 185.187.119.246 mta119-246.msgfocus.com. 185.187.119.247 mta119-247.msgfocus.com. 185.187.119.248 mta119-248.msgfocus.com. 185.187.119.249 mta119-249.msgfocus.com. 185.187.119.250 mta119-250.msgfocus.com. 185.187.119.251 mta119-251.msgfocus.com. 185.187.119.252 mta119-252.msgfocus.com. 185.187.119.253 mta119-253.msgfocus.com. 185.187.119.254 mta119-254.msgfocus.com.
