I am familiar with the "SSL handshake" and how it works between client and server, I am just trying to comprehend what happens after its all over. Say you go through the process of buying something through an HTTPS website. After it is all said and done that information has to be decrypted right? Where does your data go? Is your data decrypted and stored in a database of the company where you purchased your product?
SSL only encrypts the data as it is in transit from the client to the server, or vice-versa. If you use your web browser to connect to a web server through SSL, and send your credit card information to the web server through SSL, your credit card information is encrypted as it is sent through the internet from your web browser to the web server. But, once it arrives at the web server, it is decrypted, then there is no telling what could happen to it. Hopefully the company that operates the server handles your credit card information securely. But, we've all seen all of the recent cases of sites that have been hacked and millions of credit card numbers have been stolen.
Related
Note: I am working on this as a learning exercise and not for using on an actual website.
I am trying to learn additional ways I could explicitly or statisticly identify a user so I could look at having a sort of "confidence scale" on how securer a users session is. So I could ask the user to re-verify their email if it looks like the password or authtoken has been leaked.
If a client is using a securer https connection then I believe that connection would be encripted in a way that is unique for that connection, and I'm interested in testing and trying to understand better how that information could be gathered and how it could be used.
So, Is there a way to collect the information exchanged during the server clients TLS handshake process on the web server?
I've been testing using Node.js at the moment, but would be happy to try a different langauge or software just to test this out.
Does anyone know if the client details would only be unique for the connection, or if they should be unquie for the browser or device or network interface? (For example if a mobile device goes from wifi to mobile data and the IP address changes Does the HTTPS handshake happen again wit the same or different values?)
And does anyone know if doing something like having multiple certificate for the domain and serving different certificate to differnt users would change the clients default responces on reconnections?
I would assume that the client could probably be identified by loading unique sub domains with unique certificates, and measuring timings to see what certificates in the certificate chain had been cached, and would like to test this, but also not sure if there would be a simpler or easier way?
I have a server and a client application which runs in a web browser.
I know it is better to make client do the request directly to the payment processor (by what's called a payment page)
Having said that, I would like to know if it is considered OK in terms of security and PCI, to send the CC information to the server via encrypted HTTPS transportaion and the server will send the data to the payment processor without saving the CC information
I am using ruby on rails for the server side and a gem called ActiveMerchant with another gateway support gem and I could find a way to do the payment from the client directly to the payment processor. It seems that request should pass through the my server anyway.
This is most likely not okay, since the credit card data is still unencrypted in transit (from SSL termination to your rails server) and might show up in server logs (obviously unencrypted) as well.
The payment provider we use, offers CSE (client-side encryption), which encrypts raw credit card data on the client such that it never travels as raw/readable data through our server. The encryption is asymetric and the encryption key is only available to the payment gateway making it impossible for our backend servers to ever read that data.
We have 2 Rails app (one for front end and other for backend(api) hosted on 2 different servers. User comes to our front end app and fills the order form. We then send json request to backend and backend send confirmation json response to front end. Backend is only accessible from our office address and is setup to communicate to only our front end app.
Today we purchased EV ssl certificate for our front end app from DigiCert and everything is work fine. But since we don't have ssl certificate on backend, does that means that what ever data we are passing from our front end to backend will be unencrypted?
Do we need ssl certificate for both front end and back end servers?
Our backend only servers request to our front end app and no other clients are connect to our backend? So can I use a self-signed or cheap SSL certificate for backend?
Or shall I buy another ssl certificate from DigiCert? (bit expensive)
I have already gone through couple of stack overflow questions, and looks like suggestion is to install ssl in both servers. This is my first time trying to set up ssl certificates on servers, so just want to double check before I buy another ssl certificate for our backend app.
Update
I found few cheap ssl certificate provides, what are people suggestions towards cheaper provider like this one https://cheapsslsecurity.com.au/
SSL only encrypts data between the server and the client.
It does not make a server secure.
It only prevents sending unencrypted data over the all the little hops that data makes between client and server.
Your back-end may be in a completely separate geo location or in the the server farm next door. But, it still may travel through several routers to get there. Without SSL, the data is sent in the raw. I have a few servers, some in a different rack with the same host, and some are hundreds of miles apart. Going from rack to rack in the same geo loaction still requires hops over various routers -assuming no VPN. So, yes, if you are very paranoid and do not have a VPN between the front end and back-end, then secure the back-end. But all this does is encrypt the data between the two. It does not make a server 'secure'.
What does this mean? Asuming your back end has no http presence (not discoverable on the web) then SSL on the backend is probably overkill. Why? Becaue the only people who know it exists are employees - and no amount of SSL is gonna protect the server from anyone who knows it exists or how to access it.
Neither will SSL protect you against other attacks such as SQL Injection. For example, the Equifax breach which Equifax claim was a bug in Apache Struts (although my guess is that there was more to that than meets the eye).
SSL is a band-aid on a flawed system. It does not make a server secure. All it does is encrypt data between the server and the client.
Yes, you will need SSL for your backend. that is the important place where all the logic and data is being stored. On the front-end not so important, but if you are tackling with payment or any other confidential information yes, you do need it in front-end.
Risk of Using Self-Signed on Public Sites
The security warnings associated with self-signed SSL Certificates
drive away potential clients for fear that the website does not secure
their credentials. Both brand reputation and customer trust are
damaged.
I will totally agree with this article, not to use self-signed SSL, especially when dealing with payment. For internal testing, you may. But while in production, highly recommended not to use it. Instead go with SSLs that are with Certificate Authority
Ref: https://www.thawte.com/ssl/
I'm trying to figure out the best way to send info back and forth between my server and another company's server. Basically, the other company processes the sales of my software, then goes to my server to activate the software. My software hits my server every time it loads to get the activated license. My server is blocked from external SQL queries (won't run queries from the other companies server), so I somehow have to pass data back and forth with their server.
Being new to this kind of thing, I'm looking for opinions on how best to do this regarding how to do this securely (I already know how to write code). For example, is an encrypted GET request sufficient where I can just decrypt info passing in a link? SSL with data in XML? I appreciate any thoughts and direction you can give.
Thanks in advance!
It sounds like you can put up a web or web services server? Have your server only accept connections by HTTPS, and require client authentication. Have the other company's server contact your server using HTTPS with a POST request.
Your server will need to present an SSL certificate that the other company's server recognizes as authentic - either you need to get a certificate issued from a CA, or you can create a self signed certificate and have the other company install that certificate in their server's trust store. The other company will also need to present an SSL certificate that your server recognizes - in this case, it should be a self signed certificate that you install in your trust store, so you aren't accepting connections from just anyone who has a CA issued certificate.
Your software can contact your server with an HTTPS GET request. The certificate requirements for your client software will be the same as for the other company's server, as described above.
This arrangement will prevent (a) anyone from impersonating your server, (b) anyone from impersonating your partner's server when posting to your server, (c ) anyone from eavesdropping on your client software's connections to your server and getting their user keys that way.
I have a small device that contains a client program which communicates with a server over the internet. Pretty standard stuff.
I have a requirement that the server be able to authenticate messages coming from the device, meaning that all communications from the device be from the authentic client and not from some impostor. It's assumed that an attacker can reverse engineer the client and also load his own programs onto the device.
I'm questioning whether this is even possible. I could certainly load a client certificate into the client, but an attacker could get to this and use it himself. The cost of the device must remain low, so no fancy hardware tricks. Any ideas on how I could do this?
Depending on the device, and what kind of abuse you are talking about, you could use a scheme that needs some kind of activation. Like entering a master key into memory only - so its lost if power is lost - a technic used on some crypto cards.
A way to counter stolen devices could involve some kind of lease of keys that needs renewal on a regular basic by specifying a secret.
A way to counter an imitation/copy could be to works with a common state between the client and server that keeps changing. Like negotiating new encryption keys regularly.
We use a similar thing with our apps and web services. We call it ApiValidation where the client in each request to the service adds a header called ApiID which the server can decode to see if the client is authorized or not.