NotionCommotion Posted January 22, 2015 Share Posted January 22, 2015 This is a long post, but most of it is backup information, and I hope I don't scare you away. I created a self signed signature as follows: # Create the key openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -aes-128-cbc -out key.pem # Create the certificate signing request openssl req -new -key key.pem -sha256 -days 365 -out csr.pem # Remove pass-phrase from the key cp key.pem key.pem.tmp openssl rsa -in key.pem.tmp -out key.pem rm -f key.pem.tmp # Sign the certificate. openssl x509 -req -in csr.pem -signkey key.pem -sha256 -days 365 -out crt.pem cp key.pem /etc/pki/tls/private/key.pem cp csr.pem /etc/pki/tls/private/csr.pem cp crt.pem /etc/pki/tls/certs/crt.pem rm -f key.pem rm -f csr.pem rm -f crt.pem I've since gotten a Class 2 certificate from StartSSL so I will not need the above created crt.pem. I used the content in csr.pem above, and saved it as /etc/pki/tls/certs/startssl.crt. I set it up using example.com as the primary domain and *.example.com as the secondary domain./etc/httpd/conf.d/ssl.conf includes more, but for discussion purposes, includes the following: LoadModule ssl_module modules/mod_ssl.so Listen 443 <VirtualHost _default_:443> SSLEngine on SSLProtocol all -SSLv2 SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW SSLCertificateKeyFile /etc/pki/tls/private/key.pem #SSLCertificateFile /etc/pki/tls/certs/crt.pem SSLCertificateFile /etc/pki/tls/certs/startssl.crt SSLCertificateChainFile /etc/pki/tls/certs/sub.class2.server.ca.pem SSLCACertificateFile /etc/pki/tls/certs/startssl.crt </VirtualHost> /etc/httpd/conf/httpd.conf includes the following: ... ServerName example.com ... NameVirtualHost *:443 <VirtualHost *:443> SSLEngine on SSLCipherSuite SSLv3:TLSv1:+HIGH:!SSLv2:!MD5:!MEDIUM:!LOW:!EXP:!ADH:!eNULL:!aNULL #SSLCertificateFile /etc/pki/tls/certs/crt.pem SSLCertificateFile /etc/pki/tls/certs/startssl.crt SSLCACertificateFile /etc/pki/tls/certs/startssl.crt SSLCertificateKeyFile /etc/pki/tls/private/key.pem SSLCertificateChainFile /etc/pki/tls/certs/sub.class2.server.ca.pem ServerName example.com ServerAlias *.example.com DocumentRoot /var/www/html </VirtualHost> When I restart httpd, I get the following: [root@vps tls]# service httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ] [root@vps tls]# tail /var/log/httpd/error_log [Thu Jan 22 12:25:24 2015] [notice] caught SIGTERM, shutting down [Thu Jan 22 12:25:24 2015] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Thu Jan 22 12:25:24 2015] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366) [Thu Jan 22 12:25:24 2015] [notice] Digest: generating secret for digest authentication ... [Thu Jan 22 12:25:24 2015] [notice] Digest: done [Thu Jan 22 12:25:24 2015] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366) [Thu Jan 22 12:25:24 2015] [notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.5.18 mod_ssl/2.2.15 OpenSSL/1.0.1e-fips configured -- resuming normal operations [root@vps tls]# tail /var/log/httpd/ssl_error_log [Thu Jan 22 12:25:24 2015] [warn] RSA server certificate wildcard CommonName (CN) `*.example.com' does NOT match server name!? [Thu Jan 22 12:25:24 2015] [warn] RSA server certificate wildcard CommonName (CN) `*.example.com' does NOT match server name!? [root@vps tls]# When I access the site, the browser states: This Connection is UntrustedQuestions... Does not the actual VirtualHost extend the _default_ VirtualHost? Why is SSLEngine on required in both (seems to have error when I remove it in the actual VirtualHost)? Should the keys be in the _default_ VirtualHost, or the actual one, or both? Seems like some of the directives needs to be in both which surprised me as I thought one was extended off the other. When is SSLCertificateFile and SSLCACertificateFile required? Why the difference? Why the errors and untrusted connection? Thank you Quote Link to comment Share on other sites More sharing options...
Jacques1 Posted January 22, 2015 Share Posted January 22, 2015 (edited) As to the second question: SSLCACertificateFile is used for client certificates. This is where you put your private CA in case you're using public key authentication (you probably don't). The StartSSL CA certificate wouldn't make sense in this context. What exactly does the trust error in your browser say? Edited January 22, 2015 by Jacques1 Quote Link to comment Share on other sites More sharing options...
NotionCommotion Posted January 22, 2015 Author Share Posted January 22, 2015 (edited) What exactly does the trust error in your browser say? Thank you for your reply Jacques. Is this what you are looking for? Are they talking about my Linux servername? If so, how could that work if one had multiple VirtualHosts operating on the same machine with different certificates? bbb.bbb.sites.example.com uses an invalid security certificate. The certificate is only valid for the following names: *.example.com, example.com (Error code: ssl_error_bad_cert_domain) EDIT. Ah, I think I have a clue. The browser doesn't have a problem with https://blabla.example.com/, only when there is a second level subdomain. Edited January 22, 2015 by NotionCommotion Quote Link to comment Share on other sites More sharing options...
NotionCommotion Posted January 23, 2015 Author Share Posted January 23, 2015 I asked StartSSL the following, and below is their reply. I suppose given the low price, I shouldn't be surprised. My intent was to have domains such as bla.someSpecificSubSite.sites.example.com. Requiring a separate certificate for each someSpecificSubSiteis not an option. Is this typical? Hi, I recently enrolled with your Class 2 validation. All works with *.example.com (i.e. foo.example.com). What do I need to do to use *.*.sites.example.com where * is a wildcard? For instance, foo.bar.sites.example.com where foo and bar can be anything? Thank you You can request certificates like foo.bar.sites.example.com, but not like *.*.sites.example.com. You also can request certificate like *.bar.sites.example.com, which means you can use "*" as a wildcard certificates once, not twice. Quote Link to comment Share on other sites More sharing options...
Jacques1 Posted January 23, 2015 Share Posted January 23, 2015 Protecting multiple subdomain levels requires a certificate with one SAN (Subject Alternative Name) per level: yourdomain.com *.yourdomain.com *.*.yourdomain.com etc. Technically, this is perfectly possible. But it's rare and will be expensive. It seems DigitCert offers this, but you should double-check that they indeed support multiple wildcards in a single SAN and not just multiple wildcard SANs. It might also be a good idea to do a test run with a self-issued certificate to see how browsers react to multiple wildcards. What exactly do you need the subdomains for? Quote Link to comment Share on other sites More sharing options...
NotionCommotion Posted January 23, 2015 Author Share Posted January 23, 2015 What exactly do you need the subdomains for? Same old problem: http://forums.phpfreaks.com/topic/292550-two-sessions-in-a-given-script/ I have a site called mydomain.com and you can sign up to get your own microsite called public.jacques.sites.mysite.com with a backend called admin.jacques.sites.mysite.com. Quote Link to comment Share on other sites More sharing options...
Jacques1 Posted January 23, 2015 Share Posted January 23, 2015 Well, simply protect the core application with your current wildcard certificate. This isn't perfect, but it's still much more secure than stuffing all microsites into a single domain or something like that. Quote Link to comment Share on other sites More sharing options...
NotionCommotion Posted January 23, 2015 Author Share Posted January 23, 2015 (edited) Thank you Jacques, I will probably end up going with public.mysite.com and admin.mysite.com with wildcards for each. Not ideal due to the reasons discussed previously (bobs_site.public.mysite.com can write cookie to parent .public.mysite.com). Also, I wanted to give the ability of the owner of the microsite to change their admin domain (i.e. bobs_site.admin.mysite.com is changed to bobs_site.randomname.mysite.com). I suppose I could do so, and inform the user to expect the browser to state it is untrusted. If so, I probably also should put another domain level in place so it will look like bobs_site.randomname.admin.com in order to keep control of my first level subdomain space. Turns out https://www.digicert.com/ssl-certificate-comparison.htm doesn't offer multi-level subdomains. That being said, their customer service appears to be stellar. Chat Content: [6:19:23 AM] Are multi-level subdomains available such as *.*.mysite.com? Adam: [6:19:34 AM] Hello Michael. Welcome! [6:19:57 AM] There are not any *.*. wildcard certificates. Michael: [6:20:08 AM] Okay, thank you Adam. Adam: [6:20:48 AM] Are there any other questions I can help you with? Michael: [6:20:57 AM] No, I appreciate your time. Edited January 23, 2015 by NotionCommotion Quote Link to comment Share on other sites More sharing options...
CroNiX Posted January 23, 2015 Share Posted January 23, 2015 (edited) Do you really need so many levels of subdomains? That's confusing and ugly and provides no real benefit that I can see. Why not just www.yoursite.com //main site joeq.yoursite.com //Joe Q's main site joeq.yoursite.com/admin (Joes admin panel) Then the cheaper *.yoursite.com can be used Edited January 23, 2015 by CroNiX Quote Link to comment Share on other sites More sharing options...
NotionCommotion Posted January 23, 2015 Author Share Posted January 23, 2015 (edited) Do you really need so many levels of subdomains? That's confusing and ugly and provides no real benefit that I can see. Why not just www.yoursite.com //main site joeq.yoursite.com //Joe Q's main site joeq.yoursite.com/admin (Joes admin panel) Then the cheaper *.yoursite.com can be used Several reasons, but please continue reading as I think you are on to something with the admin part. joeq.yoursite.com can write cookies to .yoursite.com. I guess I need to live with this situation, or at least that joeq.sites.yoursite.com can write a cookie to .sites.yoursite.com. Might want to use other first level subdomains and not compete with joeq and the like over them. This is probably my primary reason. One level might make it more intuitive that the user is accessing a "site" domain. In regards to using /admin as the admin panel, that had been my original approach. Not only does it eliminate the need for another wildcard certificate, I could allow the user to change their admin folder name without the elusive multi-tier subdomain. Thank you; I will concider going back to this approach. My original implemenation included a directory in /http for every site and an index.php file (or symbolic link) in both /http/joeq/ as well as /http/joeq/admin/ which I really didn't like. How would you advise setting up Apache (without creating a directory structure for each microsite as I previously did) so that joe.sites.yoursite.com goes to one location and joe.sites.yoursite.com/admin goes to another? Or if they both go to the same location, being able to differentiate the two using $_SERVER and PHP? Furthermore, I might have something like joeq.sites.yoursite.com/index.php?x=1&y=2&z=3 and joeq.sites.yoursite.com/admin/index.php?x=1&y=2&z=3. Or if I get fancy, show it as joeq.sites.yoursite.com/1/2/3 and joeq.sites.yoursite.com/admin/1/2/3 and use Apache rewrite each. If I can't use fancy URLs, I suppose this is okay, but just need to know what I am getting into. Thanks Edited January 23, 2015 by NotionCommotion Quote Link to comment Share on other sites More sharing options...
CroNiX Posted January 23, 2015 Share Posted January 23, 2015 (edited) AFAIK, if each subdomain sets a cookie for the specific subdomain, like "subdomain.domain.com", instead of ".domain.com", and domain.com only sets cookies for "domain.com" and not ".domain.com", then the cookies would be secure and only accessible by the domain/subdomain that set them. The cookie should also be a "secure" (https) cookie and be set to HttpOnly. https://www.owasp.org/index.php/Testing_for_cookies_attributes_%28OTG-SESS-002%29 As far as if the url starts with '/admin', you could use mod_rewrite in apache and detect that, and if it starts with that pass the request to "admin.php" or something. Something like: RewriteRule ^admin/?(.*)$ admin.php/$1 Edited January 23, 2015 by CroNiX Quote Link to comment Share on other sites More sharing options...
NotionCommotion Posted January 23, 2015 Author Share Posted January 23, 2015 I believe the only risk with cookies is when JavaScript gets involved. I used the following to prove it to myself: http://forums.phpfreaks.com/topic/292517-cookies-per-subdomain/?p=1496965. As you indicate, HttpOnly should elimiante the concern. In regards to the admin part, my hopes were to identify whether it was subdomain.mydomain.com/index.php or subdomain.mydomain.com/anyAdminName/index.php. If the later, I would use the DB to dermine if anyAdminName was the admin name for subdomain, and act accordingly. Also, if I understood you correctly, they wouldn't be accessing admin.php, but index.php in the admin directory? How could this be implemented? Quote Link to comment Share on other sites More sharing options...
Jacques1 Posted January 23, 2015 Share Posted January 23, 2015 You're both missing the point. First of all, I fear those are rash actions. I understand that you're worried about the HTTPS issue, but that doesn't mean you should accept any risk only to have a fancy HTTPS certificate. It doesn't make sense to remove all locks from one door only to have twice as much locks on another door, because now the system as a whole is actually weaker. Yes, HTTPS is important, but XSS protection is just as important, if not more important. “Why not just put the admin area behind a path like /admin?” Because then you lose all XSS protection. Any vulnerability in the public area immediately compromises the admin area as well. Since the public area is generally the weakest link of an application, this is a very bad idea. You don't have this problem with separate domains, because the Same Origin Policy isolates one domain from another. You misunderstood the point I made about cookies. This is not about your cookies. This is about cookies set by an attacker to do a session fixation attack, break your CSRF protection (if you use cookies for that) etc. The fact that a microsite can set cookies for your entire application is a serious problem, and there is no easy fix. This needs to be approached with an HMAC or session isolation, but that's a different discussion. HttpOnly doesn't do much and is a rather naïve approach (although I do recommend it for defense in depth). An attacker doesn't necessarily care about the actual content of a cookie. Often times they just want to use the cookie. For example, it doesn't matter that you don't know the session ID as long as you can use it to gain the victim's privileges. Quote Link to comment Share on other sites More sharing options...
NotionCommotion Posted January 26, 2015 Author Share Posted January 26, 2015 Thank you Jacques, I understand that the concern are not my cookies but about others maliciously setting them, however, I must admit I don’t know fully how to deal with it. For my specific circumstances, I believe, try as I might to make them, both frontend and backend users will not always utilize strong passwords. I also don’t think the site will be a target for sophisticated international hackers, but local amateurs might attempt to gain inappropriate access by guessing common passwords. Furthermore, frontend users are not able to post content to the frontend reducing the treat of XSS attacks. Lastly, I believe HTTPS is required for the microsites from a security as well as marketing prospective. A crutch for weak backend user passwords is making the admin section site specific. For instance, if public access is bobs-site.public.mysite.com, I don’t want every admin section to use the same key work (for instance “admin”) such as bobs-site.admin.mysite.com. However, it appears that CA SSL certificate like *.*.sites.mysite.com are not available or are cost prohibited. Putting the admin area behind a path like /admin or /blabla allows me to do so, however, results in possible XSS vulnerability. So it appears that I am damned if I do and damned if I don’t, and have to chose the path of least evil. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.