Locking down access to webmail on your national or private cloud service

For many, if not most of our partners in the network operator & application hosting space the challenges of identifying the subscriber has become nothing short of a nightmare in recent times. Password based security by itself no longer is manageable, secure, and aggravates the user experience of the service by adding layers of frustration to the authentication sequence. Lets look at some techniques that will mitigate some of these challenges and provide some added assurances to the customer experience that the service security policies are effective, but also thoughtful of the impacts on the user.

We have in CommuniGate Pro a certificate authority built into the platform and for the purposes of our chat today we will focus on using TLS certificates in combination with multi-factor authentication to lock down access while providing a reasonably smooth user experience. We should point out that this type of model is typically in demand for business subscribers, especially governmentally regulated industries, i.e. banks, air transportation, government agencies and healthcare are especially pushed to conform to certificate based security topologies. One of the challenges of the topology is the management and setup of the devices which is normally mitigated when the system is operated by IT departments and “bring your own” devices are not permitted, unless they are put under such management.

So what the heck am I talking about in simple terms? Certificate based TLS sessions are where the client system, laptop, desktop or mobile have installed a signed digital certificate that is presented to the service during the SSL connection session. That means that the computer trying to “login” must also have this certificate to present to the service as a means of determining that the computer itself is authorized, not just the user credentials.


The illustration above shows  a typical deployment at a network operator with a Pronto! based web access method for the subscribers. In the private cloud all the users must conform to 3 added policies to “get into” the service:

  1. Password and user challenge / response is met with a biometric scan using our multi-factor API and mobile client
  2. TLS certificates must be present on the client machines and presented to the server
  3. The network that the machine is coming from must be on the list in the server policy

Furthermore the network operator has also placed several “good practice” policies on the public access network for reception and transmissions of messaging content. In many cases we are seeing that inner agency traffic, for example from the police to the justice department are required to also present TLS certificates. Adding TLS certificates on the SMTP sessions is highly recommended to “tamp down” the flames of SPAM and create policies that control what you want coming in versus the model of “cleaning up” the junk after it arrives with a open SMTP policy.

It should be stated as sometimes there is confusion about “email encryption” and if that means encrypting the mail itself or the transportation of the mail. For our purposes of this discussion we are talking about  TLS / SSL and that is all about the “transport” not the encryption of the email itself. Email encryption is performed in the CommuniGate Pro platform with a cousin technology called S/MIME that we will discuss in another blog posting.

In the hosting model we have two “doors” that we are talking about locking or having keys for the user to open. First is the “web access” or Pronto! webmail that combines all its communications over a HTTP/S session. That means we can send/receive mail, VoIP calls, and perform actions on the calendar or directory with a single socket connection; in this case HTTP/S using the TLS certificate to control whom and from what system can open the door. The other doorway we are talking about controlling is public or external to the “domain” in question. That means if in my example of the police and the justice department are on separate services, each can install the TLS certificates on their respective SMTP/S configuration profiles and lock the doors for any abuse or fraudulent attempted access.

While most of our talk is centered around the installation of TLS certificates on the access computers, we should not lightly skip over the way the user should authenticate. In the end of the day, if a computer is stolen, or accessed by an imposter, all they need is the fingers on the keyboard. Often times security breeches are performed by persons with mal-intention within the organization or on the periphery, like a partner or even staff with access for cleaning and maintenance of the facilities.

Password based authentication is only designed to determine that a password is “correct” not that the person is actually who they say they are. Biometric authentication in a multi-factor policy is the best method today for adding a layer that is far more precise, but also simple to use compared to lengthy passwords that are difficult to enter and remember for the user. CommuniGate Pro has build a simple to user and re-brand mobile client for TouchID on iOS devices and Android systems with biometrics sensor features. We can also “fall back” to secure session data code transmissions or least secure SMS code validation but strongly suggest that biometric scan policies are enforced for the most reliable and traceable security policy on your cloud service.


CommuniGate Pro PKI infrastructure

Tips for protecting the SMTP session on CommuniGate Pro 


The ever increasing opportunity for National Cloud value added services

Seems to me…… where & “with whom” you “float your ballon” is just as important as what “type” of ballon you have to fly. Translating that into the terminology of Cloud Computing; what legal rights you have based on who’s stuff (service) you are using might be more important than the type of technology you have for security. That means if I use great passwords or encryption, it might be less important than if all my “stuff” is at the end of the day controlled by legal agreements I submitted to knowingly or un-witingly.

For the purpose of this post we want to put aside technology to another discussion or topic, meaning lets chat about the benefits or ramifications of security, i.e. encryption or access controls another time.

The underlying subject of security that often times gets overlooked completely when discussions are made about cloud computing is the legal umbrella you might be walking under when using a cloud based system or service. Most of us click, and few of us read those EULA’s that come with all the popular email, chat or voice/video systems in use today. Often times these “agreements” include in one way or another the accord that “by using this service you explicitly agree that the jurisdiction controlling this usage License is xxxx”. Furthermore, many of these click-wrap agreements (for free and paid cloud services) indicate that your rights are forfeited and you should stop using that service if you do not agree to the jurisdiction.

Many telecoms and network operators have a massive opportunity in that they more than many can provide a National Cloud that has a lot of benefits for not just the public, but we also find many governmental organizations demand a local provider. I recently was speaking with a “post office” that uses one of our partner network operators for email. Kind of ironic huh? I mean mail man using email, but OK jokes aside they too must have a way to communicate electronically by inner-agency messaging systems, and want those to be “housed” inside the country domain, both physically and legally.

I have found that at root or the core of a value for many of our partners is the legal ability (licensed operator) to issue phone numbers. Over the top services have in many cases overwhelmed many operators globally. But “nationally” the potential is just as it is today with phone numbers if you think about @Internet address space that can be nationalized. Many of the weaknesses of technical limits can also be overcome when a domain is controlled, regulated and managed on a national level.

Take the example of a provider issuing internet address space on a National Cloud for email. Not only can the legal use License be placed under local laws and regulations (benefit for business owners), but security and abuse can be managed far more than un-managed public messaging services. Simple case, a user or domain is fake or sending abuse mail, it can be de-commisioned. Adding to this, the National Cloud operator can add value by certifying the origin of the mail, the contents of the mail (not having been tampered with) and much more, making email professional and far more trustworthy.

With over 200 Network Operators as partners, we have a unique visibility on the values of Unified Communications as a Service and understand what not to do, what works and what does not work. If you are a service provider and are interested to provide high value business communications in your region we have a unique way to work; as a partner relationship not a vendor/client. We listen and we adapt to your local requirements better than most.