We extensively use a third party app that we'll call thirdparty.com. thirdparty.com and mysite.com have a common navigation and look and feel, so to the users, they think they are always on mysite.com.
What we're going to do is start url rewriting 3rd.mysite.com to display thirdparty.com, to make it look even more like a seamless experience. This also gives us access to thirdparty.com's cookie, because it will be written as mysite.com.
thirdparty.com has an SSL cert that they use for a few select transactions (basically just login). When you call https://3rd.mysite.com/login, you get a 404 as mysite.com does not have SSL. So we're going to install an SSL cert to the 3rd.mysite.com subdomain to alleviate this problem.
The question is, if we install a EV SSL certificate, will the user see that, or will it relegate to the cert from thirdparty.com? I can think of reasons for this to work both ways, but am looking for a definitive answer. If they see the SSL cert, then there's no sense wasting money on the EVSSL. If they see the EVSSL, I'd think that would be a big opening for phishing if someone was doing this illegitimately.
Cheers
If user agents see the site as thirdparty.com they are going to require an https certificate for thirdparty.com. So if that's an EV cert, then they are indeed going to see the green glow. Of course, you will want to make sure any communications between thirdparty.com and mysite.com should be appropriately secure.
(BTW: rfc2606 for example domain names.)
Disclaimer: I'm not really competent to answer this question, but this is stackoverflow.
Related
I've seen this question around here on the forums only what I wish to know slightly differs from the ones I already read I suppose.
I will give you an example of the problem I am facing:
Let's say a hacker has managed to infiltrate the system and is able to spoof a DNS. Now if this hacker would clone a website, let's say this website is facebook, what I have read so far he would be making a HTTP website, because HTTPS would show up as faulty.
Now what I'm wondering is that with modern SSL it would seem like everyone is able to get his own certificate for his website. So if someone would connect to that website it would say the connection is trusted because it's SSL with a legit connection.
So what if this hacker would add a certificate to his cloned/spoofed phishing website? Wouldn't this mean that me as a user would go to his facebook page, and in the search bar it would say the connection is legitimate ( Because he added a certificate ) ? Because if that would be the point it would be necessary to check the certificate of every website I open at all times to see if it's actually the certificate that belongs to facebook (For example.)
Please let me know if anyone has any knowledge about this I am very curious to see how this works!
Provided that
Let's say a hacker has managed to infiltrate the system and is able to
spoof a DNS.
means that the attacker has control over the records for the name facebook.com (in orther words, he can point www.facebook.com to an IP of his choice) then yes, your scenario is correct.
He would
redirect www.facebook.com to site of his
buy a certificate for www.facebook.com
Someone going to that site would then see (www.facebook.com would be the domain)
This means that the traffic to access to this site is correctly secured between the browser and that site, and nothing else. Specifically, this does not tell if the site actually belongs to Facebook.
There are some sites which go one step further, with Extended Validation Certificates, where the issuer does some checks to "ensure" that the certificate is delivered to the actual owner of the service. You the see something like
As you can see, the owner of the site is visible right on the toolbar. Other browsers usually use a bright green toolbar to signal such sites.
Not sure if that is what you're asking, but you have trusted CAs imported to your browser (by default).
The attacker would need to have a key signed by trusted authority for this particular domain. I do not expect that to happen.
Another option would be breaking the key - very unlikely with current technology/regular updates made by major browser providers.
Major browsers providers are deprecating vunerable alghorighms to make sure you're OK.
For instance - Recently for that reason SHA1 got depreceated.
See here for more details on SHA1:
https://blogs.windows.com/msedgedev/2016/11/18/countdown-to-sha-1-deprecation/#pjXdGbOji3itBI7v.97
https://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html
https://www.google.com.au/search?q=firefox+sha1+deprecation&rlz=1C5CHFA_enAU714AU715&oq=firefox+sha1&aqs=chrome.1.69i57j0l5.2293j0j4&sourceid=chrome&ie=UTF-8
)
To summarize - your browser will let you know that there is 'something wrong' with the site (warning instead of green box).
Simply check the green box (and domain). Keep your browser updated.
Also for more information about SSL handshake see here: https://www.ssl.com/article/ssl-tls-handshake-overview/
So I made a contact form in Laravel 5, that's completely working. It basically posts the email, name and message to a variable and sends me an email with them. Is this secure enough for real life use without an SSL cert?
My project files are outside of the public_html folder if that makes a difference. I want to have this usable (security-wise), but don't want to pay a ton of money for an SSL cert on a site hardly anyone will go on.
Any answers appreciated
SSL is always recommended, but if the contact form shouldn't get any sensitive data, then you can live without it.
Though now you can get SSL certs for free from LetsEncrypt.
Hello I would like to implement a payments on my web site.
I have a requirements that to do it in iframe with hidden address bar.
But in this case user would't be abble to see that we are using HTTPS protocol for sending data and e.t.c
Does is it good practice or it is looks like security issue ?
I don't think it is a good idea to hide HTTPS information from end users. If you look at any web security for dummies kind of guide, they all say that when you enter private/financial information etc make sure your address bar display the lock etc.
Even though you may in your HTML that you are using HTTPS, do you really expect users to "view source" your HTML and/or use Fiddler etc? No right?
So, do the right thing- show HTTPS URL.
BTW, from security perspective, if the first page you serve is NOT over SSL, someone could just modify HTML and inject a malicious HTTPS link with valid cert. That is why it is very important to have SSL enabled on your whole website.
No wonder HTTP 2.0 is going to be all SSL :)
Technically you don't need HTTPS if you are using iFrames for checkout. Ofcourse the 3rd party website is always protected... BUT since you cannot explain this to your customers/clients, so you have to have a HTTPS even you are using iFrames even it is secure but to make your customers feel actually that they secure you should have SSL (HTTPS).. Or I know many of your customers will simply leave your website... SO YOU DO NEED IT... YES
I am new to development and at my new job we have this issue where on a sub-domain users are getting the error you see below but when they go to the base domain (e.g: domain.com) they don't see that.
I am supposed to solve this but not sure what might be causing it. I am not looking for somebody to solve this for me but if you can outline possible reasons why, i would be very thankful.
First thing: open up the "Technical details". They will give you more information, information you might or might not yet fully understand, but it still have the necessary info.
Basically, SSL (https) certificates are created for a specific domain. If the domain name changes (from e.g. example.com to foo.example.com), the certificate can not be used without a security warning popping out.
You need to create (either by self-signing or purchasing) separate SSL certificates for all the host names/domains under which the site will be accepted, to avoid the security warning. An alternate option is to purchase a wildcard certificate for the entire domain and sub tree (ie: *.example.com).
There are, to the best of my knowledge, no other ways around this; it's one part of how the HTTPS security is established.
When you're running HTTPS, you should have a different certificate for each server (subdomain) not each domain and the client should trust it if you don't want them to see this error.
You can use a wildcard certificate also. It would inherit through all subdomains.
So this is a somewhat broad question, I know, but I'm hoping someone who is wiser than I can provide a summary answer that can help wrap up all of the ins and outs of SSL for me.
Recently I watched a video of Moxie Marlinspike giving a presentation at BlackHat, and after the hour was up, I thought to myself, "It doesn't really matter what I do. There's always a way in for a determined hacker." I recall his final example, in which he demonstrated how even using a redirect when the user typed in an HTTP address to go directly to HTTPS, there is still an opportunity in that transition for an attacker to insert himself via MITM.
So if browsers always default to HTTP, and users very rarely enter an HTTPS address directly in the address bar, then an attacker who is listening for accesses to Bank X's website will always have an opportunity during the HTTP -> HTTPS redirect to gain control. I think they have to be on the same network, but that's little consolation. Seems like Marlinspike's point was that until we go straight HTTPS as a standard rather than an alternative, this will always be a problem.
Am I understanding this correctly? What is the point in redirecting to HTTPS if an attacker can use MITM during the transition to gain control? Does anyone have any clue as to preventative measures one might take to protect himself? Would redirecting via javascript that obfuscates the HTTPS links (so they can't be stripped out in transit) be of any help? Any thoughts would be appreciated!
You can use HSTS to tell the browser that your site must always be accessed using HTTPS.
As long as the browser's first HTTP connection is not attacked, all future connections will go directly over HTTPS, even if the user doesn't type HTTPS in the address bar.
There are no actually any information leak in HTTP/HTTPS redirect if implemented properly on server side (i. e. if all dangerous cookies are marked as "HTTPS only" and inaccessible for JavaScript).
Of course, if end user doesn't know anything about security, it can be hacked, but from the other hand, if you user doesn't know even basic security rules and there are not system administrator who will explain it to user, it is possible to hack such user in so many ways that HTTP to HTTPS redirect problems is not really trouble.
I saw many users who downloaded and run unknown EXE files from server just for promise to "win 1000000 dollars", which is also a good way to hack them (even better than to exploit redirection, if you run as EXE in user computer, you are already king here and can steal any user cookies under default security settings).
So, if user collaborates with hacker and helps hacker to hack his own computer, yes, such user will succeed to be hacked, but security is about professionals who ready to protect himself and not about user who may be publishes his PayPal cookies somewhere on Blogpost and after that surprized that he is hacked.