The recent US DoD Advisory on Hardening Remote Access VPNs recommends the following:
Avoid selecting non-standard VPN solutions, including a class of products
referred to as Secure Sockets Layer/Transport Layer Security (SSL/TLS) VPNs.
These products include custom, non-standard features to tunnel traffic via TLS
Read here:
https://media.defense.gov/2021/Sep/28/2002863184/-1/-1/0/CSI_SELECTING-HARDENING-REMOTE-ACCESS-VPNS-20210928.PDF
Apart from the possible performance bottlenecks by using a Transport layer VPN, what exactly are other security concerns ? (assuming TLS v1.3 is used)
Using custom or non-standard features creates additional risk exposure, even
when the TLS parameters used by the products are secure.
How ?, or Why ?
Related
Should I use HTTP or HTTPS to communicate between services on my virtual private network (VPC)? What are the risks (if any) of using HTTP in such scenario?
My naive reasoning is that given the inherent privacy of the network, HTTP should be suffice for internal communication between servers inside of said network. Am I wrong to make such assumption?
I've searched through GCloud VPC documentation, yet can't find anything regarding this question. I've also found this article on AWS HTTPS, yet again no indication as to whether one or other should be preferred.
I'd link up more sources, but I can not find any articles arguing for either.
As per my understanding, a VPC network isolates the traffic and puts some security measures in place that prevent your traffic from being seen from a different VPC. That being said, the security of the resources is a shared responsibility in cloud environments. In case there is a security breach inside GCP that allows someone to gain access to my VPC and sniff the traffic, if I'm using HTTPS, the communication is encrypted and I am adding another layer of security. Therefore, I would always go with the safest option (HTTPS).
I want to connect to Snowflake using ODBC, and I saw that it is SSL enabled by default(Does snowflake support ssl?).
Appreciate where I can have it formally from Snowflake, as I yet to find as such documentation..
Thanks !
All snowflake connectivity is to:
https://..snowflakecomputing.com
Even the ODBC connector is just a wrapper for HTTPS calls to then https URL above. That means that everything in snowflake, Web UI, JDBC, ODBC, snowsql, Python etc all runs over HTTPS and SSL.
It's also worth noting to meet the security standards here, all traffic must be SSL:
https://www.snowflake.com/snowflakes-security-compliance-reports/
I would read the following document, which has a bunch of different sections that reference SSL, OCSP, and openSSL key-pair settings.
https://docs.snowflake.com/en/user-guide/odbc-parameters.html
Appreciate where I can have it formally from Snowflake
The Snowflake Security Policy specifies that all customer data in transit is encrypted with TLS 1.2.
https://www.snowflake.com/wp-content/uploads/2018/07/2018July12-Snowflake-Security-Policy.pdf
Reference section 3.1. Encryption of Customer Data, which states "Snowflake leverages Transport Layer Security (TLS) 1.2 (or better) for Customer Data in-transit over untrusted networks."
This statement applies to all customer data in transit, so ODBC is included.
As coTurn server provides the option to create multiple realms throught its database, and when turning the server on, a default realm can be provided in the configuration.
When configuring the webRTC client to access TURN, it only allows the URIs, username and credentials properties, but does not have any way to provide a realm or origin (as coturn supports origin).
The default realm is always considered.
If I try to utilize the realms concepts, providing different user credentials under different realms in the webRTC client config, the server accepts only turn requests with users under the default realm.
Questions
Is there a way to overcome this matter to provide realms/origin to the server?
If not, why have realms been added to the coturn if they cannot be used?
tl;dr: the realm is pretty useless in WebRTC.
In theory TURN as a protocol includes a realm. However, see the detailed example in the RFC this typically isn't sent in the initial allocate request, only subsequent ones. In theory the client could store the realm and use it for subsequent requests.
In WebRTC, the peerconnections are pretty much independent. There is no way to configure the realm in the ICE server configuration
See also this response from working on that in chrome/webrtc.org
My understanding is that SSL combines an encryption algorithm (like AES, DES, etc.) with a key exchange method (like Diffie-Hellman) to provide secure encryption and identification services between two endpoints on an un-secure network (like the Internet).
My understanding is that SASL is an MD5/Kerberos protocol that pretty much does the same thing.
So my question: what are the pros/cons to choosing both and what scenarios make either more preferable? Basically, I'm looking for some guidelines to follow when choosing SSL or to go with SASL instead.
It's quite difficult to compare SSL/TLS and SASL, because SSL/TLS is a communication protocol, whereas SASL is a framework, integrated with other protocols. (In fact, you can use both at the same time in some circumstances.)
In addition, you're mentioning Kerberos, which is indeed an authentication protocol (which can be used with SSL/TLS or SASL or independently both). Your question seems to suggest that whether or not to use Kerberos one of the main sub-problems you should choose first.
SASL is essentially an indirection layer to allow for pluggable authentication systems and data security in existing application protocols (e.g LDAP, SMTP, Subversion, ...), although these protocols need to be aware of this extension (e.g. SMTP auth). Whether and how it provides secure authentication and data encryption depend heavily on what underlying mechanism is used within this framework. Here is an example from the svnserve documentation: "The built-in CRAM-MD5 mechanism doesn't support encryption, but DIGEST-MD5 does".
If you want to use Kerberos with SASL, you will need another level of indirection: GSS-API (which is most commonly used with Kerberos, but can also allow for other mechanisms). (Note that GSSAPI in the context of SASL seems to imply Kerberos anyway, unlike its GS2 successor.)
The general goal of SSL/TLS is to secure the communication (integrity and confidentiality) between a client and a server. The client should always check the identity of the SSL/TLS server, and it provides mechanisms for server to check the identity of the client too. What it can do also depends on how it is configured. SSL/TLS is most commonly used with X.509 certificates: that's how a browser can check the identity of an HTTPS server. Servers can also be configured to request the client to use a certificate to identify themselves (client-certificate authentication).
However, if you want to use Kerberos, you can use TLS Kerberos cipher suites. This is much less common, but they are implemented in the JSSE.
Its implementations usually provide APIs similar to what you get with plain TCP connections: in Java, once configured, you can more or less use an SSLSocket as you would use a plain Socket. This doesn't require specific awareness by the protocol on top of the socket, although some protocols have explicit commands to switch to SSL/TLS from a plain connection (Implicit v.s. Explicit SSL/TLS). It can also provide authentication. In Java, the JSSE is the default SSL/TLS implementation, which gives you access to SSLSocket (or SSLEngine if you're brave enough).
You might want to read "When to use Java GSS-API vs. JSSE", which is similar to "SASL vs. SSL/TLS" (although it doesn't seem to have been updated for a while, since the JSSE does support Kerberos cipher suites now, at least since Oracle Java 6).
I'll admit I know less about SASL than about SSL/TLS, but doing data encryption via SASL sounds like it's going to be more work. It doesn't seem to have certain SSL/TLS features such as the Perfect Forward Secrecy offered by EDH cipher suites. There is an example that uses SASL with GSSAPI (Kerberos here) in the JGSS tutorial: you need to wrap/unwrap the data explicitly, which you wouldn't have to do when using SSLSockets.
I think your main concern should be to decide which authentication mechanism you want to use in the first place: Kerberos, X.509 certificates, or something else. This will have more impact on your overall architecture, and both can be used with SASL and SSL/TLS (more so if you use SASL with an EXTERNAL mechanism, when on top of an SSL/TLS connection).
Kerberos is very centralised. The client will need to be able to contact the KDC to authenticate, in addition to being able to contact your application server. The clients will also need to be configured to use that KDC. From a user's point of view, they can use passwords.
X.509 is more decentralised. However, you may need to deploy a Certification Authority (or use a commercial one) for your user certificates. Users will need to be given certificates and private keys, which some might find too complex.
JAAS comes into it because it's the general Java framework for dealing with authentication and authorisation. It's very closely linked to the notion of security managers. It gives you the notion of Subject and Principal. This isn't directly linked to the protocols or the communication, but rather to the way you model authentication and authorisation within your application. (It gives you a standard set of classes to do so.)
(I'd generally suggest to go through the Java reference documents that mention the words you're after: JGSS, SASL, ..., although they're not necessarily easy to read.)
SSL vs SASL
It's true that SASL is not a protocol but an abstraction layer. It's also true that SSL and SASL are kind of providing similar features. Both of them provide authentication, data signing and encryption.
SSL is done at the transport layer and it is normally transparent to the underneath protocol. For example, you can use SSL on LDAP or HTTP. However, in some cases, modification to existing protocols is necessary in order to switch to secured mode. For example, POP3 and IMAP is extended to have a command STARTTLS to initiate the use of SSL. From that angle, this is kind of similar to what SASL doing.
On the other side, many protocols are also extended to provide SASL capability. Here is the list of protocols. Again, POP3 and IMAP are two of them and they are using different commands to initiate the authentication.
So, when should we use SSL and when should we use SASL?
An obvious difference between SSL and SASL is that SASL allows you to select different mechanisms to authenticate the client while SSL is kind of binded to do authentication based on certificate. In SASL, you can choose to use GSSAPI, Kerberos, NTLM, etc.
Because of this difference, there are some situations, it's just more intuitive to use SASL but not SSL. For example, your client application is using Kerberos to authenticate the end user. Your server needs to authenticates the client. Since your client application already have a Kerberos credentials (in Kerberos terminology, a ticket), it makes sense to use the Kerberos credentials to authenticate with the server. Of course, you can always setup SSL to do the same thing. However, that means on top of the existing Kerberos infrastructure, you need to setup Certificate Authority infrasture and somehow correlate the client certificate with the Kerberos credentials. It's doable but a lot of work.
Also, sometimes, you need to use some features that available only in the SASL mechanism but not the SSL. For example, Kerberos allows you to forward the ticket from the client to the server so that the server can use the ticket to query some resources on behalf of the client. One common example is that you have a application server and a database. The client application authenticates with the application server and the application server needs to query the database on behalf of the client using client's credentials. SSL cannot provide this feature to you but Kerberos supports this. So, in that case, you have to choose to use SASL.
In some cases, you do want to use SSL but not SASL. For example, extending the protocol is not an option or you want to encrypt every single packet exchanged using underneath protocol.
How does GSSAPI relate to Kerberos and SASL
According to this wiki page, both GSSAPI and Kerberos are supported mechansim in SASL. GSSAPI is a generic programming interface. The idea is to let application writer use one single common API to do authentication, encryption, etc regardless of what protocol is used underneath. GSSAPI implements Kerberos. So, you can use GSSAPI to do Kerberos authentication.
How does JAAS relate to SASL
To be honest, I am not a Java expert. From what I read, it sounds like JAAS is just a pluggable authentication framework. I beleive the idea is similar to GSSAPI. It's to provide a single programming interface regardless of what authentication method is using. While GSSAPI is focusing on authentication and secured message exchange, JAAS is focusing on authentication and authorization. I don't find any evidence that JAAS is also one of the SASL mechanism. I believe there should be some helper classes from Java library helping you to implement custom SASL mechanisms. While implementing the custom SASL mechanism, it may makes sense to just use JAAS.
SASL is not a protocol but an abstraction layer to some auth mechanism. If you use Digest-MD5 or GSS-API as your SASL mechanism you can request SASL to completely encrypt your data traffic. This is for example what I do to talk to your Active Directory servers. You won't need SSL. What is your use case? Please elaborate!
Can anyone confirm that using a persistent outgoing TCP connection on port 80 will not be blocked by the vast majority of consumer firewalls?
That has been assumption based on the fact that HTTP runs over TCP, but of course it is theoretically possible to analyze the packets. Question is do most CONSUMER firewalls do this or not?
The feature is called ALG, Application Layer Gateway. This is where the firewall is aware of and perhaps even participates in an application protocol
There are two main reasons a firewall may do this:
Protocol support, in order to support the protocol it is necessary to snoop/participate, e.g. opening up additional ports for non passive FTP or media ports for SIP+SDP
Additional security, an ALG may function as a transparent proxy and filter protocol commands and actions to enforce policy. E.g. preventing the HTTP CONNECT method
ALGs have been a common feature of stateful firewalls for many years, though often the source of instability.
For security proscriptive environments expect HTTP to be validated and filtered either by a firewall or other dedicated policy enforcement appliance.
Residential broadband routers do not tend to have advanced firewall features. I would be surprised to find any with HTTP validation / filtering on port 80.
Personal software firewalls come in two flavours, basic and advanced. Most consumers will have a basic one that probably comes with their operating system and will not do any HTTP validation / filtering.
However, there is a rising trend in antivirus product differentiation of advanced internet content filtering for threat protection, there is significant possibility these may filter HTTP activity (but is difficult to determine with certainty from their Feature Lists).
It's almost impossible to answer this question with anything other than "it depends".
Most leading firewall vendor solutions will do this through their configuration.
You will find paranoid organisations (financial, government, military, gambling etc) will typically have such application intelligence enabled. They will detect the traffic as not valid HTTP and so block it for both security and performance reasons.
This type of feature is (these days) typically turned on by default and as you know, most people don't change a default configuration after the vendor or consultant has left.
However, some companies, where the techies don't understand or they have no power in the decision-making, will turn such application intelligence off because it interferes with business, i.e. internal apps or external apps (running on the LAN and connecting back), developed as bespoke solutions, work over TCP port 80 (hey, it's always open) and are non-http.
You don't just have to worry about firewalls though, most companies run internal proxy servers for outgoing traffic and these typically now only allow valid HTTP on port 80 and their configuration isn't changed as a proxy server is usually requested by the infrastructure and security teams and they don't want non-http over port 80. Additionally, there's also load balancers and they're typically configured for HTTP on port 80, for a variety of reasons such as content switching, rewrites, load-balancing and security.
To summarise, in my experience, that'd be a yes but I haven't worked a lot with SMEs, primarily larger corporates.
port 80 is blocked by many firewalls for example you have to add exceptions like i allow Skype or msn messenger to use port 80 for out going traffic