Some assistance on SSL required

[AllanF 0]

Hi,

 

I am using ICS TFTPServer and TWSocketServer on my Server side application (Delphi Seattle). I want to use SSL to secure the connections.

This question is more related to SSL rather than ICS. 

I have read on SSL and checked the Demo programs too. I yet need some clarity.

Mine is a backup application and will be sending critical data over the WAN. 

 

If I generate my own certificates via OpenSSL where do I keep the PEM files for the ICS Server components to access ?

Should I generate a different PEM file per customer upon installation or can I supply a common one ?

I files are large can I have only password exchanged secretly and data without encryption (My data is already compressed with AES ) ?

Regards

Allan

(Thanks for all the new features in ICS)

[Georgge Bakh 29]

If multiple server sides are planned (for each customer?) it's better to generate own certificate/key pair for each customer.

There is no much reason to use TLS for already encrypted data.

[Guest]

Yes, you don't to go through full SS/TLS implementation along with certificates validation if your data is already encrypted, using a certificate with secure connection doesn't mean you are safe, certificates without path validation and authority is useless in preventing MITM, so your problem is with reaching shared key for AES between client and server without sending the password on wire (encrypted or not because it is the same problem) here my solution for such :

 

Go to https://github.com/krisztianpinter/curve25519-delphi

and grab that file and use it to reach shared AES key with sending it over connection, this will cost you one trip ( one extra packet and one response at most ) and your client and server will have their secret shared AES key ,

 

How to do it:

1) Each server will generate its own pair private and public, you can derive the private from a password ( any method will hash or more secure way like PBKDF2) for that curve25519 you need a private key with 32 bytes length to generate the public key, the public key will be supplied to each client will connect to that server or delivered by other means like grabbing it from DNS TXT record, like i like to it with my PSK keys.

2) Client on its own will fill its private key from 32 random bytes (secure random not the one with RTL) then generate public key ( by generating i mean perform scalar multiplicaiton  base point)

3) Client has the public from server (pre-supplied when installation or setup the connection ), will perform the scalar multiplication between its private (client) and the server public the result is the master key for the AES ( the result of that multiplication is 32 bytes) and will use it for encryption, sure here you can use only 16 bytes from that and use AES128 instead of AES256

4) here the extra packet or any packet will do with additional data, which is the client public key only will be sent to the server

5) server will perform the scalar multiplication between its private key and the received client public key, the result will be the same AES master key the client had.

 

Hope this was clear .

 

The link above contain nice implementation of Curve25519 ,it is small and fast with no dependency, but you can use any other library that support Diffie–Hellman key exchange.

[Angus Robertson 574]

The latest version of the ICS FTP server includes full SSL/TLS support and will even automatically order and install free Let's Encrypt certificates, or commercial certificates if you really want to pay. 

 

The most important point about certificates is they are mostly for public domain names that can be accessed on the public internet, and the certificates are published in public logs for any to find and check.  Indeed hackers monitor those logs, and within a few seconds of a new certificate being issued expect hacking attempts to port 80.  BTW, port 80 needs to be open to order a domain validated certificate. and the ICS FTP server also has an HTTP server to satisfy the request, only runs for a few seconds until the order process is finished.

 

If you don't care about domain validation and only encryption, you can use self signed certificates which ICS will also generate.  The X509Certs component will even issue certificates signed by a private CA, I use that on my LAN for testing lots of internal servers.

 

Angus

 

[Guest]

Angus that very right and on point. 

I want to suggest a small tweak you may like, make sure that CA certificate key usage include XCN_OID_PKIX_KP_CODE_SIGNING(1.3.6.1.5.5.7.3.3) from https://docs.microsoft.com/en-us/windows/win32/api/certenroll/nn-certenroll-ix509extensionenhancedkeyusage

Then sign the clients with it, (with or without your own code signing certificate), the will client validate the server certificate against its signature certificate, thus you simplified the whole trust chain and made it more secure while ditching the headache that comes from 3rd party certificates and their restrictions.

For extra functionality server can generate its certificate from its CA for each client or for all ( means at runtime) , and take advantage of the custom extensions to pass data in trusted way to the client.

[Angus Robertson 574]

I've only been talking about server certificates here.  Client certificates are totally different and make things very confusing.  ICS clients and servers do support client certificates but not automatically and there are no samples using them, really only needed for exceptionally high security stuff like Swift bank transfers. 

 

The ICS component has properties to add digitalSignature and codeSigning extensions to certificates, not sure which OID they add.

 

Angus

 

[Guest]

I wasn't clear here, i am talking about server certificate too, but for the client to trust specific one came from server and differentiate it from a MITM while keep away from the system store( here ACME or 3rd party trusted CA by system ), code signing certificate that signed the the client can act as anchor to establish the trust chain.

[Angus Robertson 574]

Might come back this in the summer when OpenSSL 3.0 adds support for Certificate Management Protocol, which I'll try to support in ICS as well as Let's Encrypt.

 

Angus

 

[AllanF 0]

Thanks for the valuable info you have provided. Seems like I may not require any more security measures apart from what I already have. Please allow me to explain my current scenario and kindly let me know if I have a vulnerability.

 

As mentioned earlier I have TFTPServer and TWSocketServer on Server. Client machine's TWSocket is always connected to the Server's TWSocketServer. Only simple info is passed via the sockets. All files are passed via FTP (encrypted if critical).

 

When Client Socket connects to the Server Socket I validate if first OnClientData is as per my expected format else I abort that Client connection.

 

For FTP connection I send a new username and password at each connect FTP Server understands it is correct by doing a matching system between Username and Password.

 

When files are exchanged between client and server they are AES256 encrypted and the server just stores it on his machine, Server does not need to decrypt it. So there is no password exchanged for File Decryption purpose.

 

 

Edited January 9, 2020 by AllanF

[Guest]

The keyword is 

4 hours ago, AllanF said:

So there is no password exchanged for File Decryption purpose.

Meaning the server doesn't receive the decryption key ( in your case the password ) this leads to you are good and safe.

 

Nothing really need to be changed except may need to make this password and user name exchange more secure, to prevent a third party from logging to that FTP and ,delete files !?.

 

So my suggestion is use a hybrid scheme by using the DH method mentioned above to reach a shared a OTP secret instead of password, (searching the net i found this and just checked its solid https://github.com/wendelb/DelphiOTP )

The client then will use the token in the FTP login process and server will authenticate the client accordingly.

 

One thing though and it is important, client and server must be on the right time, or your server can supply the client with its time as they must be on the same timing ( the counter must be same or very close like less than "const keyRegeneration = 30")  it does need right counter to make OTP works, i believe here if you read the code of that OTP you will understand.

 

To prevent 3rd party who captured the FTP login information from login again, server must make sure that the first IP to log in is the right one.

 

That can give you better security to prevent data lose,

 

But really the sound of SSL/TLS is way better than plain connection and clients love the sound of it, so converting to TLS/SSL and FTPS will not have huge performance penalty, yes i am suggesting FTPS not SFTP, so you can have same SSL/TLS connection infrastructure for both TWSocketServer and TFTPServer .

 

As for initial question, i don't believe you need CA trusted certificate and your own certificate will do, Google is your friend here, also there is demos with each library you gonna use, free or commercial .

[AllanF 0]

True that customers will love to hear TLS ☺️

Angus has given loads of demos / Self signed certificates etc. Just wanted to know I am doing the right thing. 

Will update my Servers to use SSL. 

 

I suppose the PEM files will have to reside in my application folder itself ?

Will give each customer a new certificate (unless he has his own).

 

[Guest]

Ditch PEM and use p12 ( same as pfx)

[Guest]

You know what ignore that and use what ever you like, PEM is just fine as long you encrypt it with password, just don't leave it unencrypted.

[Angus Robertson 574]

The ICS FTP server and client already support One Time Passwords automatically, added that long before SSL/TLS became common,  In the server, set the OtpMethod to those you wish to iupport, and the server hello prompt changes to advertise OTP, which the  FTP client handles automatically.

 

Angus

 

[Georgge Bakh 29]

Self signed certificates can be validated as usual. If lets say a server certificate is self-signed than a root CA certificate which was used for signing (may be self-signed as well) should be trusted by client. If both server and client data are under control it's possible to make the CA certificate trusted. That's how browsers work after all.

Diffie-Hellman key exchange by itself doesn't protect from MitM attacks.

[AllanF 0]

Considering all the advice I prefer to use the P12 files and stick to SSL as it will work for both Sockets and FTP.

 

Just wanted some more clarity. 

 

Is the Username and password used in the connect statement of the FTP Client and Authenticated at the FTP Server have to do anything with preparation of the SSL Certificates ? 

 

I am trying to create Self Signed Certificates using  IcsSslBuildCerts.bat and I get several files. I don't know which to use , whatever combination is not working. 

RootKey.pem, RootReq.pem, RootCert.pem, Root.pem

ServerCAkey.pem, ServerCAreq.pem, ServerCAcert.pem, ServerCA.pem,

ServerKey.pem, ServerReq.pem, Server.pem, ServerCert.pem
ClientKey.pem, ClientReq.pem, ClientCert.pem, Client.pem

 

Using ICS demo 01cert.pem, 01key.pem and cacert.pem works fine.

 

Edited January 10, 2020 by AllanF

[Guest]

6 hours ago, AllanF said:

Is the Username and password used in the connect statement of the FTP Client and Authenticated at the FTP Server have to do anything with preparation of the SSL Certificates ? 

No.

 

6 hours ago, AllanF said:

I am trying to create Self Signed Certificates using  IcsSslBuildCerts.bat and I get several files. I don't know which to use , whatever combination is not working. 

None.

 

I am looking at the IcsSslBuildCerts and there is these lines

Quote

%OPENSSL_BIN%\openssl pkcs12 -export -inkey RootKey.pem -in RootCert.pem -out Root.p12 -passin pass:%PASS% -passout pass:%PASS%

 

%OPENSSL_BIN%\openssl pkcs12 -export -inkey ServerCAKey.pem -in ServerCACert.pem -out ServerCA.p12 -passin pass:%PASS% -passout pass:%PASS%

See that "pkcs12", there should be Root.p12 and ServerCA.p12 , they should be generated.

 

 

Now i have a suggestion : as you getting pass this to SSL/TLS, you should spend some time getting familiar with X509 certificates and their format, this is common knowledge and there is minimal knowledge you should have, this knowledge will benefits you, no need to study them in depth but at least you should recognize few critical things, as is there private key , what is the type of the public key, what is the common name/unit name,.....

and i suggest to do and download xca from https://hohnstaedt.de/xca/index.php , why this? because it is GUI and will greatly speed up your understanding the certificates and what do they contain of data.

You can use it instead of OpenSSL command to generate your Root and CA and Server certificate and export them, the important thing that you can see the chains and how do they link and chain, this will you help be more confident with your setup.

When in doubt and you will, test your server against web browser and see its response.

 

There is countless resources on the internet about certificates, none will help you unless do it your self at least once, so please spend an hour or two and trust me you will feel way better, you will not need to ask questions too.

[Angus Robertson 574]

7 hours ago, AllanF said:

I am trying to create Self Signed Certificates using  IcsSslBuildCerts.bat

Those are really old files and should have been removed a long time ago.

 

The primary demo and documentation for X509 certificates is OverbyteIcsPemTool.dpr which will display, create, and convert numerous certificate formats, it is complex but will do almost everything the OpenSSL command line tool will do, in code. 

 

For a simple self signed certificate, there is an ICS function CreateSelfSignedCert in OverbyteIcsSslX509Utils.

 

Angus

[Angus Robertson 574]

I would suggest reading ICS wiki FAQ_Using_TSslCertTools which explains all about certificates, and FAQ_Order_SSL_Certificates.  There are other FAQ on how we handle trust stores. 

 

Angus

 

[AllanF 0]

A huge thanks for all the help you'll have provided. Truly appreciate.