I was in discussion with a vendor to implement a backup solution and as flexible as most cloud applications nowadays, it needs to be access from anywhere on Internet without VPN or any special tunneling.

From high level perceptive, the solution has a web-ish application that client talks to and it needs to talk to a MS sql for some database/datastore operation. I am a little concerned to expose the application to Internet even just port 443/HTTPS as assured by the vendor rep. As traditional design, I could put the application into DMZ and leave SQL inside. I am still not 100% comfortable but I do not have a scenario in my mind to prove my concern.

I need your help convince me that it is not safe to expose web application to Internet even just port 443.

closed as unclear what you're asking by schroeder, RoraΖ, Xander, ThoriumBR, Jens Erat Mar 25 '15 at 21:23

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • the port doesn't matter, what matters is the security of the service answering that port – schroeder Mar 25 '15 at 18:14
  • 2
    I've read your question a few times and I'm confused: what is the proposed solution/problem? Exposing a port without any firewall or protections? Is the vendor objecting to being put into the DMZ? What's the question here? – schroeder Mar 25 '15 at 18:38

Port 443 is the default port for HTTPS communication using SSL/TLS. As such, if you can reject and/or redirect traffic on port 80 (the default unsecured HTTP port) and reject all other ports, and if you can trust your web server OS's TCP/IP and TLS implementations, this scheme is as safe as any publicly-accessible computer communications endpoint can be made, from a hardware/firmware perspective.

However, this only proves that the means of communication is secure, and that this comm channel is the only way to get in. That can still mean the application communicating over this channel has vulnerabilities. Someone could hijack the remote system and use the secure channel to request information the person normally wouldn't be able to get. The remote system itself could store information it retrieves from you in an insecure manner. The component of this solution residing on your webservice could be vulnerable to any number of attack vectors that don't require breaking TLS itself; a third party could, for instance, perform a replay attack to corrupt data by making your server do things twice. Or, they could properly negotiate a TLS connection with your server and then pound on the relatively weak authentication system provided by the application.

In short, just because you can expose only port 443 to the world and accept only properly-negotiated TLS connections through it does not necessarily mean your system is secure. You must also trust that the application using the TLS channel is properly implemented to prevent various attacks carried out by systems using the channel. If you cannot trust this application, you should not use it.

  • Cool! Thanks for the information. As of the application level TLS implementation, I can only assume vendor does decent job when coding... – m1xed0s Mar 25 '15 at 18:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.