Secure Communications
HTTPS
In the HTTP world, secure communications is accomplished by using the HTTPS protocol which uses Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to encrypt communications. Both the client (HttpCommand) and the server use certificates for secure communications. The certificates serve a couple of purposes:
- They provide bi-directional encryption of the data sent across the link.
- They can help provide authentication of the client and/or the server.
HttpCommand Behavior
HttpCommand attempts to figure out if the connection is going to use HTTPS and what port to use based on:
- The protocol, if any, that you specify in
URL. - The port, if any, that you specify in
URL. - Whether you have provided certificate information for the request.
HttpCommand will use HTTPS if
- You provide certificate information by using the
CertorPublicCertFileandPrivateKeyFilesettings. - You specify
'https'as the protocol. - You don't specify a protocol, but do specify a port in
URLof 443.
HttpCommand will use port 443 if you do not specify a port in URL and HttpCommand has otherwise determined from the above criteria that the connection should use HTTPS.
Encrypted Communications
In most cases, the use of certificates is hidden when using the HTTPS protocol because HttpCommand will automatically generate an "anonymous" certificate. This is sufficient to provide secure, encrypted, communications.
Authentication
Certificates can provide information about the identity of what is at the other end of the communications link.
Server Identity
When HttpCommand uses HTTPS, the PeerCert element of the result namespace contains the server's certificate. This can be used to validate the server is what you think it is. Most certificates will have a "chain" of parent certificates that show who issued the peer's certificate and any intermediate certificates. If the final certificate in the chain is issued by a Trusted Root Certificate Authority the domain listed in the certificate has undergone validation by an entity that you can trust.
Dyalog.com provides us with an example of a certificate chain:
⊢ r ← HttpCommand.Get 'https://dyalog.com'
[rc: 0 | msg: | HTTP Status: 200 "OK" | ⍴Data: 23127]
r.PeerCert ⍝ Dyalog.com's certificate
#.HttpCommand.[X509Cert]
r.PeerCert.Chain
#.HttpCommand.[X509Cert] #.HttpCommand.[X509Cert] #.HttpCommand.[X509Cert]
⍪⊃r.PeerCert.Chain.Formatted.(Subject,' from ',Issuer)
CN=*.dyalog.com from C=US,O=Let's Encrypt,CN=R3
C=US,O=Let's Encrypt,CN=R3 from C=US,O=Internet Security Research Group,CN=ISRG Root X1
C=US,O=Internet Security Research Group,CN=ISRG Root X1 from O=Digital Signature Trust Co.,CN=DST Root CA X3
This shows that the certificate for '*.dyalog.com' was issued by Let's Encrypt whose certificate was issued by Internet Security Research Group whose certificate was issued by Digital Signature Trust Co and Digital Signature Trust Co is a Trusted Root Certificate Authority.
The good news is that in most cases you'll never need to look at the certificate chain, but it is available in the rare event that you need to verify the server you're connecting to.
Client Identity
If the service you connect to uses client certificate authentication, you will need to use a certificate when sending your HTTP request. Generally this certificate will be issued by the service provider. A certificate consists of two parts - a public certificate file and a private key file. HttpCommand allows you to specify the certificate in two ways:
- provide the file names for the public certificate file and private key file in the
PublicCertFileandPrivateKeyFilesettings respectively. - specify the
Certsetting as either:- An instance of Conga's
X509Certclass - a 2-element vector of the names of the public certificate and private key files
- An instance of Conga's
Other HTTPS Settings
HttpCommand has two more settings SSLFlags and Priority. The default values for these settings will suffice in almost all cases. If you need to use something other than the default, refer to the Conga User Guide.
Further Reading
See the Conga User Guide Chapter 5 for more information on Conga's secure communications and X509Cert.