Map CIS benchmark recommendation to Severity

Benchmarks
The CIS benchmarks are designed as an auditing tool, not as a risk assessment tool. The purpose of a benchmark is just that: a measurable point of comparison. The outcome of a CIS benchmark is a pass/fail determination.
This idea works for system configuration because you can set well-known and serviceable configuration sets that meet the most common objectives. While you could make a server do whatever you want, the vast majority of servers have a very narrow use case, and we can set a common configuration benchmark for servers used in these pre-defined ways.
Severity
The concept of "Severity", like one has in Vulnerability Management tools, tries to help provide relevance to a negative finding. In VM tools, this is a calculation of the anticipated impact of the finding. A question asking "what's the worst that could happen?"
This question is nuanced when we are talking about an unexpected vulnerability in how something was coded or used. But when talking about the configuration of system that is working as expected, "severity" does not make as much sense. In a configuration, a setting is either what you want or it isn't.
Priority
But you end up running a configuration benchmarking tool and you have failures. What should you do to determine:

if you should accept the failure
what to fix first

Because we are talking about configuration options, this is not something that you can pre-determine or have someone else figure out for you, unless there are obvious experimental or dangerous settings, or the settings are a form of "hygiene" (password length, permissive defaults, etc.). You obviously rate those settings with a higher priority.
To prioritise your findings, you need to perform a classic risk assessment. Only you can know which configurations are necessary for your environment, and only you can analyse the impacts of misuse/abuse of those settings. What would be risky for one environment would be low risk in another.
The benefit of the CIS Benchmarks, even though they seem overkill, is that you can meet the benchmark and know that you have a strong configuration. They are "Best Case". They take away the need for doing too much risk assessment for each possible configuration option. To accept a failed finding requires you to do the work the benchmark was designed to save you from. You want to determine a "Good Case". And for that, you just need to do the classic work of risk assessment.


How do social media apps notify you when someone else takes a screenshot of your profile?

This is a major revision to my previous answer, which was factually incorrect. It is posted as a new answer in order to prevent baiting-and-switching of votes, as I feel the current answer is not the same as the one I had initially posted.

In order for a social media application to notify a user that a screenshot has been taken, the application has to know that a screenshot is being taken.

To my knowledge, neither iOS, nor Android, have a framework intended to detect screenshots. This means that developers need to find a workaround on how to detect a screenshot being taken. There are several questions on Stack Exchange regarding this (such as here and here) and the method that seems to be recommended the most is to observe for a new file to be created in the screenshots directory.

Since an application can determine if it is currently in foreground or not, and can receive a notification when a new screenshot is being created, the application can therefore determine if a screenshot of the application is being taken. The application can then react accordingly, such as notifying users that a screenshot of their profile or conversation has been taken.

Keep in mind that I cannot answer exactly if this is how Instagram or other Social Media applications implement this. This answer explains how it could be done.


Casual email that includes a P-Card Account number and expiration date - does this violate PCI?

From your question it seems the employee was emailing their own card data to someone? That should not be a PCI problem, because the company didn't mishandle card data controlled by the company. I'd say that they should be given a stern talking to because it might show poor judgment, and maybe have a record of that talk, but I don't think it will be an issue for you.

They cloudy bit in this might be, what did the receiver of the email do with the card data? There might be someone who could make a case that it then becomes company controlled data. Was that card EVER used to do a legit transaction with the company as a customer?

Similarly, if a person choses to send all of their own health data to someone, that wouldn't be a hipaa violation either, because that law similarly restricts data being handled by the organization, not by the person who's data it is.


Why are the embedded versions ("overlay", "embed") of the auth0 lock considered safe?

Why does auth0 still offer me to embed their login on my site?

The authentication system that auth0 provides doesn't offer users to enter their "auth0 customer credentials". Rather, the credentials are unique to the site that's embedding the form.

You are right in that it's only safe to enter your login details in an embedded form if you trust the page hosting it. That's why social login features like "Login with Google" always redirect you to a secured login page of the social identity provider and should never ask you to enter your credentials directly on the initial (potentially untrusted) page.


You misread the page about sniffing packets; it is already paranoid and alarmist, but not to that point.

When producing a DSA signature, the signature engine works in a group which is embodied by a modulus p (a big prime number) and a group order q (a smaller prime, divisor of p-1). These values are part of the public key. For each signature, the signature engine must use a random number generator to produce a random value k which MUST be chosen uniformly in the 1..q-1 range. The "uniformly" term is very important. If the choice of k is biased, then it allows for key recovery after observing a number of signatures. Whether this is critical or not depends on the bias. A relatively small bias (e.g. k is generated as a sequence of bits of the size of q, then reduced modulo q) will incur an "academic" break with key recovery after about 263 signatures: an attack, yes, but not practical. On the other hand, if the random generator is so botched that it always outputs the same value for k, then two signatures are sufficient to recompute the private key. Sony deployed such an utterly failed RNG/signing system.

What this amounts to is that if the implementation of a signature algorithm is bogus, well, it may leak important data, including the private key. This is true of any cryptographic algorithm, and RSA is not exempt. Singling out DSA is unwarranted.

(What can be said in all neutrality is that DSA and ECDSA require a source of randomness for each signature, which is a relatively heavy requirement for embedded systems such as smartcards. Solutions exist; when I have time, I work on the issue. Edit: this is now a published RFC.)

As for key size, the current standard specifies sizes of 1024, 2048 and 3072 bits (that's the size of p). An older version of the standard allowed only 1024 bits, while an even older allowed all sizes multiple of 64 from 512 to 1024 bits. A number of deployed implementations of DSA are a bit lagging behind the 2009 standard, and thus allow only 1024-bit keys.

A 1024-bit DSA key is not a critical risk. As far as we know, DSA appears to be at least as strong as RSA with the same key size, and in practice a bit stronger. DSA relies on discrete logarithm and the current DL-break record is for 530 bits, while the current record for factorization (RSA) is 768 bits. Best known algorithms for factorization and DL have a lot of similarities, but the final step (where a lot of fast RAM is needed) appears to be more expensive with DL than with factorization. Thus, right now, a 1024-bit DSA key is not a true security risk. Especially since, for signatures, we have less to worry about future break than for encryption; and DSA is signature-only.

The main issue with DSA is that it is not as widely supported as RSA; when it is supported, it may have limitations (e.g. limited to 1024-bit keys, or usable in conjunction of only a limited set of other cryptographic algorithms). These limitations are not intrinsic to the algorithm, but reflect the state of the market, which is dominated by RSA. However, it is currently quite fashionable to switch to elliptic curve variants of DSA and, correspondingly, the market is slowly (very slowly) shifting towards more support for (EC)DSA.


Terms for differentiating between key-exchange and public-key cryptosystem

RSA - is a way to encrypt/sign data. The protocol has data as input on the one end of the channel and the same data as output on the other end.

DH - is a way to generate keys. It takes no user data as input on any end of the channel. And it has a big random (not uniformly distributed) number as an output, the same on both ends.

Yes, RSA is often used to encrypt symmetric session keys, but it's only one way to use it. In that case keys are generated outside of RSA protocol, and are only transmitted via RSA.


Data Retention Laws for ISPs in North America

One significant argument against data retention laws is that data retention laws increase risk for everyone.  If ISPs save data, then they themselves become a juicy target for hackers, because anyone who manages to hack the ISP gets access to lots of sensitive data about their customers.

A good reference would be this paper:

Risking communications security: Potential hazards of the “Protect America Act”, Steven M. Bellovin, Matt Blaze, Whitfield Diffie, Susan Landau, Peter G. Neumann, and Jennifer Rexford.  IEEE Security & Privacy, 6(1):24-33, January/February 2008.

Make sure to read about the penetration of the Greek wiretap system, which allowed unknown parties to spy on important Greek political leaders.  In that case, deploying the surveillance system actually made Greece less safe, not more.

Another argument data retention laws is that they violate people's civil liberties and their privacy.  Arguably, people have a right to privacy in their online activities, at least when they are legal.  A mandate to store all of this information against their wishes arguably violates that right, and exposes them to risks they might not consent to.

A third argument against data retention laws is that, in the US, most ISPs already retain a good deal of data, so we may be talking about something that is not a serious problem in practice.  (Of course, I make no claim that the current situation is perfect or that law enforcement might not wish additional information -- merely that the current status quo may be good enough that controversial legislation is not warranted.)

If you want to read concerns raised by privacy groups in their own words, you can read CDT's resources on data retention policy and EPIC's resources on data retention policy.

Keep in mind that I'm just trying to help you identify some of the arguments against data retention here, since you asked what those arguments might be.  I'm deliberately avoiding taking a position on the ultimate policy question of what the law ought to be, as this is not the right place for a policy debate on that topic.  Please don't use this thread to start a debate on the topic.

P.S. See also What are the laws regarding ISP recording IP addresses? How would they know who had which?.


what can hackers do with a hacked router?

I'm wondering what could a hacker do if he had access to my router?

An attacker (the hacker) could do anything if Telnet or SSH access is available (probable). If the router's shell environment allows writes, then the attacker could run echo "binary contents of executable">executable;./executable which could be used to execute any executable. The attacker could do anything that the modem does using software (intercept, modify content received or sent).

Even without Telnet or SSH access, the attacker could use the web admin utilities to change DNS entries and redirect any website to a malicious one.

In any case, communications over HTTPS (including passwords) will not be compromised as the data is encrypted before reaching the router.

  My router does not show my external IP.

All routers must have an IP as they send IP packets which have an IP address and destination.

PS: It's same situation here in India across multiple service providers.


Your question is rather broad, touching on several different subjects. It may be better to take some of the details and put them in a separate question.

Is it enough to forbid su and allow sudo in order to keep the traceability of the administrator actions?
... can sudo command have utility without a strong sudoer configuration ? which ones ?

Unrestricted sudo has a couple benefits over su.

Each sudoer can use his personal password. This way you do not have to re-distribute the root password if it is changed.

sudo can be configured to log activity. If your syslog configuration writes to a remote location, then it becomes difficult for someone to cover their tracks.

However, unrestricted root access is still 'unrestricted'.

If you do not use a remote syslog server then tracks can easily be covered.

For convenience, folks often will use sudo -s to get an interactive shell. This allows you to get bash autocomplete on restricted directories. Unfortunately, the syslog benefits are void if a person is allowed to run sudo -s. Also there are many alternatives to sudo -s that can allow commands to be run without specific logging.

(I can imagine a scenario where a user does a lot of sudo actions before deleting his bash_history)

bash_history is not to be used as a history trace tool. It is only for user convenience.

Is there another source beside .bash_history useful to keep traceability? can such a file be updated by an administrator (with sudo)?

Any files on the server can be updated by a person with unrestricted root access. (whether via sudo or su)
How to trace the activity of a root user may be the subject of a different question. I believe advanced configurations of SELinux can do this, but it is probably not practical. I don't know of any other way to trace activity of a root user.
As I said if you have any logging that will have to be written to a remote log server to keep those from being erased by the attacker.

is it possible to restrict sudo -i and sudo -s in the configuration ?

To answer you verbatim, this may be possible, but is beyond the scope of this post. Consider creating a new question.
However, this will not solve your problem. For example, one could use sudo su instead of sudo -s. One could use sudo sudoers, or update the crontab, etc.
The only way to solve this is to 'restrict' the sudo abilities using a whitelist. As you said, this is not nearly as common, but is certainly the only way to accomplish the goal of reliable traceability with any level of detail.
Hope this helps. Feel free to ask for clarification on my answer, or post a more specific question if you have new questions based on what you learned so far.


Firewalls are generally classified into three main categories these are

Stateless/StateFul Packet Filters
Application/Proxy Firewall
Web Application Firewall/Reverse Proxy Firewall

Each type of Firewall operates at different layers in a TCP/IP stack and has its own pros and cons. You are actually using an Application/Proxy Firewall which imposes significant overhead if connections are not managed. It will be create a bottleneck if we keeps connection opened as firewall is maintaining state for each connection. For more detailed answers review this figure and have a read on Application Proxy Firewall.


What does the URL token do in phpMyAdmin if it's not preventing CSRF?

The token URL param is indeed a anti CSRF token. This is from the commit message fixing the vulnerability:

  Bring back token validation to GET requests

  This is necessary to avoid CSRF on SQL queries. This is really more a
  short term fix, proper fix (to be implemented in master) is to avoid
  accepting SQL queries from GET requests.

From this, we can gather that the vulnerability was the result of two mistakes in combination:

Accepting SQL queries - a state changing operation - from GET requests. This is deviating from the philosophy behind the HTTP verbs and in general a bad idea.
Not checking the CSRF token for GET requests.

It looks like phpMyAdmin originally didn't differentiate between GET and POST that well. E.g. the token is in a URL param, not a hidden form field, and the code uses $_REQUEST to check for it.

Then someone tried to fix it, disabling state changing GET requests as well as the token check for GET requests since it was no longer needed. Unfortunately, they failed at the first but not the second, and hence the vulnerability was born.


SQL injection: how to find urls to attack to

SQL injection: how to find urls weak to SQL Injection attacks.

First, you have to understand the different types of SQLi, here.

I will speak here about In-band Injection, the classic one. divided into 2 types:

Error based SQLi
UNION based SQLi

Error Based SQLI

Goal: Gathering database structure information by Displaying SQL Errors on the target website. In some cases, you can enumerate the entire database with those.

Finding a weak URL: Using Google Dorks. Yes, google is helping you finding weak urls.

example: inurl:"product.php?id=" site:.ru

Here you are asking Google to list Russian site with product.php?id= in the URL.

Why?

Because we want to find a page which is directly talking to the database. In most of the case you want to search for those patterns: *.php?parameter=n

Alright, but how do I know this URL is weak to SQLi?

You have to put a ' or %27 just after the parameter's number and press enter:

http[:]//w34ksite.com/product.php?id=1'

If a SQL Error appears there is some probability that this website is injectable.

UNION Based SQLI

Goal: Leverages the UNION SQL operator to combine the results of two or more SELECT statements into a single result.

the following block is a material I wrote for my infoSec students.(Offensive security class)

weak site:

http://w34ksite.com

first step

Find an URL that potentially sends SQL queries, like this one:

http://w34ksite.com/products.php?category=1 this URL list products, regrouped in the category named 1

Try to remember that an URL ending with * ? * = * will, in most cases, communicate with a SQL Database, we want to exploit this.

The second step

Translate the products.php?category=1 part of URL into a SQL query. Yes, in this scenario (and in a lot of website in production) this piece of URL is a disguised SQL query:

products.php?category=1 --> SELECT * FROM products WHERE category=1

The third step

Can we inject the category parameter? Let's try to sort the products list by adding ORDER BY n, for instance :

http://w34ksite.com/products.php?category=1 ORDER BY 1 Nothing change.

http://w34ksite.com/products.php?category=1 ORDER BY 2 Wow ! the products order have changed! We probably can inject stuff!

The n number in ORDER BY n indicate from which table's column number you are sorting the output (in this case the product's table column 2). So wait a minute, what happens if I input a number that exceeds the max number of the table? Let's try out.

http://w34ksite.com/products.php?category=1 ORDER BY 3 Order changes again.

http://w34ksite.com/products.php?category=1 ORDER BY 4 Wow! Blank page! We can deduce that the product's table has 3 column. This info is crucial for using the SQL UNION ALL operator.

The fourth step

Planning the attack. So, for example, we want to dump email addresses written in this database. And of course, the email entries are not in the product table. They should be elsewhere... You can guess table's name and more when SQL error appear directly on the web page, but no luck this time, no SQL error appears on w34ksite.com. So let's assume the email's table is named email, because we know this is this CMS default email's table name.

SELECT * FROM email --> http://w34ksite.com/email.php? Of course not. Who will be crazy enough to create a PHP page that lists the database's email? Why not password.php?

Don't forget that products.php?category=1 is our key to communicate with the database and inject things. This key open the database door, the general idea will be to use this key for displaying the content of the email table. So why not displaying the product table content (products.php?category=1) and the email table content? Yes, this is what we will do. By using the UNION ALL operator.

The UNION ALL is quite useful, you can join another SQL request by using it. For instance, let's translate again this URL part into SQL:

products.php?category=1 --> SELECT * FROM products WHERE category=1 right ?

We will now add the new query by using the UNION ALL operator and try to fetch the email table :

SELECT * FROM products WHERE category=1 AND UNION ALL SELECT *, NULL, NULL FROM email

We should have something like this :

http://w34ksite.com/products.php?category=1 UNION ALL SELECT *, NULL, NULL FROM email

Wait, what is the  *, NULL, NULL ?

Remember the http://w34ksite.com/products.php?category=1 ORDER BY 4 for testing if we can inject thing? We get a very valuable information: the number of column the product's table have. When using the UNION ALL operator, the table's column number has to be the same.

NULL: Fake an empty column.
, : Separate a column from another
* : display entries of this column

If nothing happens, try to move the * around like this:

http://w34ksite.com/products.php?category=1 UNION ALL SELECT *, NULL, NULL FROM email

http://w34ksite.com/products.php?category=1 UNION ALL SELECT NULL, *, NULL FROM email

http://w34ksite.com/products.php?category=1 UNION ALL SELECT NULL, NULL, * FROM email


Can WhatsApp recover Google Drive backups if the phone is not connected to the original Google account?

Is this story not being reported accurately?

Yes, in some way. I mean, the information you've questioned is accurate (at the first time I doubted too), they just did not explained all the details behind. So I decided to message Ronaldo Prass, the person behind this statement on the article you linked (which on free translation look like this):

  He (the scammer) will identify who are the relatives and friends. He has the chat history which he could benefit from and use to make the scam more reliable, making the victim have no questions about it

According to him, there are more deep steps in this scam which the press did not publish as it somehow "could be a recipe for the scam".

There is a major point we are forgetting here:
The scammers have someone on their side at a carrier.

With that said, it's easy to deduce that the employee have access to the victims register. Thus the scammer and the "team" behind it have all the information they need, including victim's email address. Also, the victims might have not been chosen randomly but based on their profile instead.

Well, now the attacker has the victim's email and mobile number (cloned on a new phone), all he needs is try to gain access to the account via a recovery fallback as you can see on the image bellow (that fallback actually helps the attack:  similar point here). He just asks for recovery and get full access to the desired account.

That is the first and very important part of the scam, which the press seems to avoid explaining. Only after that they configure WhatsApp on the "cloned phone" with all chat history, contacts, groups, everything.

Basically this scam is only possible (i̶n̶ ̶B̶r̶a̶z̶i̶l̶
̶b̶e̶c̶a̶u̶s̶e̶ ̶o̶f̶ ̶B̶r̶a̶z̶i̶l̶i̶a̶n̶s̶*̶)̶ with help of a carrier employee and the major vulnerability here is how easy is to them to transfer the number to another SIM card for a scammer.

* DISCLAIMER: I'm Brazilian

EDIT: As far as I am concerned, we are all safe with any kind of two-step verification, since both steps needs to be approved. In this case the scammer will fail at one of them. This scam may affect only people without two-step verification and with a recovery phone set.


How to create a OSx pen testing environment

Whichever tools you are used to using on Kali, find OS X versions for them, install and use.
For appsec, Some tools like Burp Suite are platform independent as Burp runs on JAVA which i primarily use and the commercial version is reasonably priced too, OWASP ZAP, w3af, BeEf framework, Nikto etc are all available for download too.
If u are referring to network pentesting, u will find NMAP pre-installed, and u can download Nessus from their website and netcat also comes pre-installed. U will find the move to OS X quite similar as i moved from Backtrack to OS X myself, most tools u are used to should be available on OS X too.
Just install and go with it.

You can look at downloading metasploit here:
https://community.rapid7.com/docs/DOC-1037

If there is something you are used to on other *nix system, and u cant download it for Yosemite, use :

Homebrew:
http://brew.sh/
Macports
https://www.macports.org/

, these will give u all the tools you seek and u can choose which ones to install. I would suggest, discovering your needs and then proceeding to download whatever you need, whenever you need it!

Good luck for your journey!


This is quite a common occurrence that I've seen elsewhere. I'm pretty sure that it generally occurs when a user has an insufficiently strong password and gets targetted though it may also happen via malware.

The attacker tries to hide what they have done by deleting the sent history.

The users account should be immediately suspended and the server logs used to find out what has been sent. All of the accounts in the users contact list and recent emails may also then get attacked or at least spammed and should also be warned.

Before re-enabling the users account, their password should be changed and their PC scanned for malware (more than just anti-virus) by someone with experience.

Don't forget to also check any other devices with access to the mail account.

I should note that, where I've most seen this is in an industry sector being actively targetted.


Is it safer to store valuable information on a unsecure client or send the data through the internet?

As long as the data travels inside a properly configured SSL/TLS connections, there is no security issue regarding the increase amount of data sent through the internet, the only downside would be an increased load on your server.

If you cannot trust local storage, then fetching the data from the server when it is required seems the best option from a security point of view.


How can I use a proxy appliance as HTTP Proxy & Reverse Proxy at the same time?

The first question I'd have would be, what do the web servers need to get to that's internal and requires a reverse proxy?  If I had to do this, I'd put the Proxy in the DMZ and set it up primarily as a reverse proxy.  There's no way I would put a reverse proxy internally and allow DMZ/external sources to get straight to it.

Then, once you have that tuned and working properly, set up egress WCCP to push to your proxy, taking special care to only get client subnets and not servers (I would never suggest WCCP for a server.  If you want it to be proxied, set it manually to a VIP that points to your proxies (if you have multiple)).  Where you do this is key, because some versions only support it on the egress interface of devices (I ran into this with a l3 cisco switch).  Also, as a FYI, I have had issues setting up WCCP on firewalls in the past because of the way traffic flows with WCCP, there are sometimes issues with state tables.  Bluecoat suggested that I remove the state inspections for this box, and I immediately required the business to move WCCP to the closest switch, therefore I would similary suggest putting this on another device if at all possible.

It's hard to tell from the limited information we have what the best place to setup WCCP would be.  Do you only have one firewall in your environment, or do you have a separate DMZ and internal firewall(s)?


How to secure yourself against jQuery preventDefault phishing?

If this code exists on a website, it would be one of two reasons:

The website itself is malicious (or has been compromised by a malicious person).
There is an XSS flaw on a website, and an attacker has injected that script. (Or an external resource has been compromised to the same effect.)

Disregarding any client machine/network compromises.

Other than that, this code cannot run on a website other than itself. The Same Origin Policy would prevent the code from altering (say) an Iframe to change destination links like so.

A legitimate website doing this on purpose would fall into category (1) IMO.

The only place this would be an issue would be inside an email message viewed via a web-based system when a user wishes to verify links. However, scripts should not be allowed to run inside HTML email messages. Most good providers prevent this from happening by stripping disallowed content and implementing a Content Security Policy.

  So is there any way to protect yourself against this besides changing your habits?

Use a browser based password manager. This should only allow you to fill out credentials on a URL match. If a phisher sends you elsewhere, the password manager won't give you the option to fill out the login form so the user will realise that something is amiss.

  Edit: Technically it's possible to use Flash on the phishing site
  itself and change the browser address bar with SWFAddress.setValue(),
  making it even possible to make the address bar appear as if it's on
  the right website.

This only changes the URL's hash value, which is a client interpreted only section of the URL. This cannot change the domain or path in the address bar.


Where and how to store admin account credentials for enterprise systems?

I'd rather have a password manager with 2 factor auth.  You're quite right, in that it's a target, and it's got to be one of your #1s in any kind of DR scenario. I think the advantages of one source of truth, secure password sharing, true random password generation, and granulated access control are worth the hassle of having another system to make highly available, etc.
There's so many disadvantages with using multiple copies of anything, so many ways it's open to abuse and human error...even within a small team.


Is there any method to prevent/trace DDoS attack?

No - There is no useful way to trace the source of such an attack. A DDoS will come from hundreds or thousands of machines, probably in multiple countries, and probably all unwittingly victims of an attacker.

But yes - you can prevent such an attack. You have 3 possible solutions:

Change IP addresses, so you aren't the target any more.
Buy more bandwidth so your pipe is bigger than the total bandwidth aimed at you.
Buy the services of a DDoS mitigation provider.


CREST is now being offered in the US, and Germany is looking to implement it soon. Other countries are coming on board in the near future.


Using SSL Certification in Multiple Locations

When client browsers connect to a SSL server, they check that the server name (as specified in the URL) is part of the name(s) which are present in the certificate. Exact rules are given in all their technical glory in RFC 2818, section 3.1.

For your situation, sharing the certificate between the two servers will work if they both share the same DNS name (but this may prove difficult, since they are likely to have distinct IP addresses), or if you convince your certificate issuer to give you a certificate with both server names in it (since the business model of most commercial CA relies on selling as many certificates as possible, they may object to selling you a single certificate instead of two).

One additional point is that private keys ought to travel as least as possible. If both servers share the same certificate, then they know the same private key, so the private key must have traveled quite a bit (at least from UK to South Africa, or the opposite). This can be done relatively safely (e.g. through some SSH connection) but, on a general basis, this is not recommended.


1). Yes, this behavior is expected. If a (parent)frame does not include a CSP header, the CSP on the children will not be enforced.

2). Furthermore, if you have an XSS vulnerability, the attacker can insert frames that do not contain CSP and still run the JS [according to the above statement, the JS is inside the frame which does not contain CSP].


Yes. I guess before that point, a user didn't even have to be logged in to be redirected through Facebook. But then, for some time, the user needed to be logged in to Facebook for it to work.

It is still a problem, since a quite a few people are always logged in to Facebook. Though even though a user might now have Facebook open right now, he might still be logged in, so the redirect system can still be abused for a fair share of people on the internet, depending on the audience. A login box won't apear, since Facebook will recognize the session cookie that gets sent to them.


Is it safe to backup programming projects from a possibly infected computer?

If you're concerned enough about it to wipe the machine, and you don't already have an online repository for your code somewhere like Github, then I'd suggest getting a live boot CD/USB for a Linux distribution of your choice and use that to copy the files off to external storage or cloud storage. I don't know of any way other than manually inspecting your code for changes to check for malicious modifications, however I would deem that incredibly unlikely for personal code projects unless they are widely in use by others.

Then get a real version control system with online hosting. This should be as simple as "download latest version from online repository, compare with local" in the worst case but that only works if you have said online repository.


SSL/TLS - Certificate chain validation result in "Invalid authentication type: DHE_RSA"

Your custom checkServerTrusted should not be forwarding to the standard checkClientTrusted but to the standard checkServerTrusted. The authType for Server is a keyexchange name, but for Client it is an algorithm name -- THESE ARE NOT IN GENERAL THE SAME and in the case you just encountered they are and should be different.

FIPS140 only specifies and restricts algorithms, not higher-level constructs like TLS keyexchanges, ciphersuites, and protocols. DH is approved (by 800-56A) only with some constraints that don't work for TLS, but it is allowed for a case that covers DHE_RSA by the FIPS1402 Implementation Guidance D.8 and is listed as implemented that way in almost your JSAFE version at CMVP #2057. OTOH SP800-52 does restrict TLS for most of the same systems as FIPS140, and r1 in 2014 does not allow DHE_RSA, but #2057 predates 2014. So I'm pretty sure there's no FIPS problem here.


How Is The OpenSSL Configuration File Parsed?

See man 5 config on your system or at https://www.openssl.org/docs/man1.1.1/man5/config.html .
I think you are being confused by your perception there is some nesting or hierarchy. There is not. ALL sections are at the same level, and are delimited solely by the [ name ] line. Lines consisting of ### are comments and ignored, and used only for visual clarity to the human reader. There is a [req] section and a [ca] section and a [usr_cert] section and more; none of these is 'within' any other, although an item in one section may refer to another section -- any other section -- if the code uses it as a section name. In fact the [ca] section is a stub that contains one item that points to another section, which in the upstream config is [CA_default]; this allows for keeping configurations of multiple CAs (perhaps a root and intermediate(s)) in one file if desired. If we look at the code for ca.c relevant to your example:
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/apps/ca.c#L441:
    /* Lets get the config section we are using */
    if (section == NULL
        && (section = lookup_conf(conf, BASE_SECTION, ENV_DEFAULT_CA)) == NULL)
        goto end;

where BASE_SECTION is #define'd as "ca" and ENV_DEFAULT_CA as "default_ca", and conf is a variable pointing to the data structure set up by app_load_config() when it parsed the config file.
The variable section can be set by a command line option before this code is reached; if it wasn't we look in the [ca] section for the item default_ca = something and use that as the default.
https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/apps/ca.c#L781:
        if (extconf == NULL) {
            /*
             * no '-extfile' option, so we look for extensions in the main
             * configuration file
             */
            if (extensions == NULL) {
                extensions = NCONF_get_string(conf, section, ENV_EXTENSIONS);
                if (extensions == NULL)
                    ERR_clear_error();
            }
            if (extensions != NULL) {
                /* Check syntax of file */

where section and conf are the variables from above and ENV_EXTENSIONS is "extensions". Again the variable extensions can be set (independently) from the commandline, otherwise we look in the selected (as above) section of the config for the item "extensions = something" and use that value.
Later in the code it passes variable extensions as an argument to parameter ext_sect of certify() which in turn passes it to do_body() which uses it as the section name in which to find information about the extensions to add. There may be many such sections, which we can select among either using the configuration or commandline options. And many of the items in an extension section, like subjectAltName, can refer to yet another config section, usually with @name syntax; those are (at least mostly) documented in man 5 x509v3_config.


What type of pattern should I use for my passwords?

None. Use a password manager application to generate long, random password for each site.

Make sure you are not using your master password (or a derivation of your master  password) anywhere else.

If you do not trust online or commercial password managers, then use one that is open source and works with local files.

Edit: For reference, Bruce Schneier has published in 2014 a rather complete (and very readable) blog post as to why using any kind of pattern for generating passwords is a bad idea.


eset smart security root certificate injection

probably is not included in the base "Nod32" option.

AFAIK it is included too as also NOD32 scans the connections.
FYI in previous versions of NOD32 and ESET Smart Security this feature was disabled by default.

  Is this common for modern day antivirus to inject its own root cert to preform MiTM?

Well... At least there are some well-known AVs, which do this.
And it is a very controversial topic. Especially with the recent Superfish issue and similar ad software doing the same, it may be considered a bad thing.
Of course antivirus software has a different aim than ad software, but it deploys the same technology.

It is a very easy way for an AV to inspect all the (usually encrypted and therefore not analysable) ssl/tls traffic.

  ESET forums seem to indicate that I can disable this feature and remove the root cert as long as I accept the loss of protection. Would this be wise?

If you do not like that your encrypted connections are broken by ESET, yes. Usually all AVs also scan files when they are saved on disk, so you are not without malware protection in this case.

  Is it accurate to say that since this root certificate exists, they (ESET) can see all of my web traffic in an UNencrypted format?

Yes. At least if "they" is "the ESET software using this technique". What they do with this information is another thing.

  In order to obtain a state of security, does this now require that one abdicates some of their privacy?

Again, this depends on what the software MITM your connection do.

  For what it's worth, this seems to remove the majority of the functionality for the "network security" function of their products.

It only affects encrypted (TLS/SSL/HTTPS/...) connections. You can still scan and block all non-HTTPS traffic.

As for the general issue

The general issue is that you give all trust implied with HTTPS/SSL/TLS from your browser to the software MITMing you. This matters for privacy reasons of course and also for security reasons as the implementation of such a complex protocol such as HTTPS/SSL/TLS is difficult and there may be flaws, which seriously weaken your security.
Examples were e.g. Kaspersky. Examples of vulnerabilities are:

the private key for the certificate is reused (as it was the case with Superfish e.g.), this allows anyone to MITM the connection just as the software using the root certificate can
old, deprecated protocol versions (e.g. SSLv2 or SSLv3) are still supported although it is known they are insecure
they support old ciphers (RC4, ciphers with MD5, ...)
...

As also outlined in the article I linked above - which I recommend you to read - such security software quite certainly also decreases the security of your HTTPS connection as they might not support some bleeding-edge (or even not so bleeding-edge) technology, which improves the security of HTTPS.
Examples are HSTS, HPKP, HSTS Preloading, HPKP Preloading, Certificate Transparency and so on...
It all depends on the implementation. Browser vendors had years implementing these features correctly and are constantly improving it and implementing new features, so it is very hard for AV vendors to keep up and - which is import - implement it correctly.


Tehcnically, yes..

Port forwarding allows external internet connections to contact your router, which then will FORWARD the connection to your computer's internal IP address. After the connection reaches your IP address, it will give input to the server you're running on your computer. So the security will be dependent on how secure the game server software is.

.. But not likely.

I wouldn't be too concerned. From my experience of hosting game servers and helping manage them for years, you're hardly ever targeted, and when you are it's usually just a DDoS attack. It would be very out of the ordinary for an attacker to have some exploit for your game server.


Browsing file/directory structure of a website

Can you? Yes and No.

Yes if the website is either compromised, badly secured or the owner wants the site structure to be browseable.

No in other cases.

So the right question would be: why a website's directory structure must not be browsable?

For this last question, you may read the good answers to this question: PHP files browsable: is this a vulnerability?


Here's a list of websites that maintain and provide a list of malicious sources:

https://web.archive.org/web/20160729161440/http://www.selectrealsecurity.com/public-block-lists


Why are many Security sites not using HTTPS?

In this day and age, plain HTTP should not be used at all. Period.

This may be a radical standpoint, but all the reasons that have been stated over the years just don't matter anymore. There is just no good reason to not use HTTPS.

  I don't do anything confidential, so my site doesn't need HTTPS.

Any attacker with Man-in-the-Middle capabilities can modify your site to include malicious code. Not using HTTPS endangers your end users.

  HTTPS has such high overhead. My servers would fry!

No, this is an urban myth. The site "Is TLS fast yet?" dismantles this myth in detail. The overhead required for TLS is negligible.

And just on a side note: The performance impact for your users is magnitudes higher when you decide to include jQuery to add a class to a <div> as if you were to enable TLS.

  But certificates are expensive! I'm just a private person doing a personal homepage!

Certificates are absolutely free from Let's Encrypt.

  It's so difficult. There's like private keys and certificates and all those things and I'm confused.

Certbot automatically generates keys, certificate signing requests, takes care of validation and your server configuration.

All you have to do is type the following:

sudo certbot --apache

And if you use apache, Certbot has now successfully added your certificate.

But why do big companies still not use HTTPS if it's so easy?

Because some companies still firmly believe in these myths. Aside from that, their infrastructure may depend on ancient hardware, back then when computers were mechanical and debugging meant pulling literal insects out of the relays. Okay, maybe not that ancient, but still pretty old.

Lots of that older software doesn't work well with modern cryptography. While technically it may be possible to solve this, the budgets of IT teams, both in terms of time and money, is limited. And if they have to choose between investing the time to get HTTPS running on their website, or setting up an internal web application that the vast majority of employees desperately need, their priorities may be elsewhere.


How could users in Backup Operators group escalate its privileges?

So to resume your query, you want to know if the Backup Operators group
  (local and domain) can escalate privileges to the Administrators group. Based on my research (source) and after reproducing the steps bellow in my lab (2012 R2), my answer is YES.

Steps:

Ensure to be member of the Backup Operators group
Open an interactive session on a domain controller. If server is not virtual, physical access to the rack will be required. If server is virtual, proper access to the virtualization control center (like VMware vCenter) will be required
Once logged in, dig into C:\Windows\SYSVOL\domain\Policies{xxx}\MACHINE\Microsoft\Windows NT\SecEdit\ folder and look for a file named "GptTmpl.inf" which looks like the following image:

Make a copy of this file and add the SID of the desired account as shown below. To obtain the SID of an account by PowerShell, use the following command : [wmi] "win32_userAccount.Domain='',Name=''"

Backup the file
Restore the file and redirect it to the real SYSVOL location, overwriting the existing GPO
Wait for GPO to refresh or force GPO refresh (gpupdate /force)

  For your information, a member of the Backup operators group can:
   - Can back up and restore files regardless of the permissions that protect those files

  Can back up system state
  Can interactively logon (RDP excluded) on all servers (including DC)
  Can logon to shutdown a server


Penetration Testing authorization from AWS

Yes, you need authorisation for a penetration test of any service running on the AWS infrastructure, whether or not it’s a service directly managed by Amazon themselves. Source: personal experience and discussion with my AWS account manager. Remember, your pen test will be testing things like AWS security groups and network ACLs as well as your own service.


Which memory modules are known to be vulnerable to or secure against Rowhammer/Flip Feng Shui?

The research paper itself which uncovered this did not specifically identify the manufacturers by name. In fact, they anonymized them on purpose. Suffice it to say that it would be reasonable to assume it was the majority of DRAM modules that have been recently manufactured:

From the paper:

  As listed in Table 3, we tested for disturbance errors in a total of 129 DDR3 DRAM modules.  They comprise 972 DRAM chips from three manufacturers whose names have been anonymized to A, B, and C. 8 The three manufacturers represent a large share of the global DRAM market.

Source: Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors


They generally have a very layered approach. Here are some things I've either implemented or seen implemented at large organizations. To your specific question on smaller businesses you generally would find a 3rd party provider to protect you. Depending on your use case this may be a cloud provider, a CDN, a BGP routed solution, or a DNS-based solution.

Bandwidth Oversubscription - This one is fairly straightforward. As you grow larger, your bandwidth costs drop. Generally large organizations will lease a significantly larger capacity than they need to account for growth and DDoS attacks. If an attacker is unable to muster enough traffic to overwhelm this, a volumetric attack is generally ineffective.

Automated Mitigation - Many tools will monitor netflow data from routers and other data sources to determine a baseline for traffic. If traffic patterns step out of these zones, DDoS mitigation tools can attract the traffic to them using BGP or other mechanisms and filter out noise. They then pass the clean traffic further into the network. These tools can generally detect both volumetric attacks, and more insidious attacks such as slowloris.

Upstream Blackholing - There are ways to filter UDP traffic using router blackholing. I've seen situations where a business has no need to receive UDP traffic (i.e. NTP and DNS) to their infrastructure, so they have their transit providers blackhole all of this traffic. The largest volumetric attacks out there are generally reflected NTP or DNS amplification attacks.

Third Party Provider - Even many fairly large organizations fear that monster 300 Gbps attack. They often implement either a DNS-based redirect service or a BGP-based service to protect them in case they suffer a sustained attack. I would say CDN providers also fall under this umbrella, since they can help an organization stay online during an attack.

System Hardening - You can often configure both your operating system and your applications to be more resilient to application layer DDoS attacks. Things such as ensuring enough inodes on your Linux server to configuring the right number of Apache worker threads can help make it harder for an attacker to take down your service.


Can we build network topology using passive fingerprinting?

Passive methods analysing traffic that comes into a single system are unlikely to work for you unless you have a very small network topology. Using tools like P0f or OSSIM you will learn what other subnets exist, but only if they connect to your box. You won't learn where they are in relation to each other, or even necessarily get a full picture of all the subnets in a network.

What you want to capture is the routing protocol traffic. Routers use protocols such as OSPF, EIGRP, and the like to send routing updates to each other. If you can see those you could build at least a partial network topology, how complete depends on the protocol and where your collector is in it. If you are in an OSPF stub area it will be extremely limited, if you are closer to the core it would be much more complete. Your system won't get any of this information unless you are running a span off of a network device because your system isn't participating in the routing protocol's multicast groups.


In SSL/TLS, the group (modulus and generator) used for DHE cipher suites is entirely up to the server. OpenSSL (the library) can be configured to use a specific group; with the command-line tool (openssl s_server), this is a matter of using the -dhparam option; otherwise, the DH parameters can be included in the file containing the certificate itself.

This page contains some information, including this:

  To use perfect forward secrecy cipher suites, you must set up Diffie-Hellman parameters (on the server side), or the PFS cipher suites will be silently ignored.

So the library does not use "default DH parameters"; it is up to whatever software uses the library. In the case of the command-line tool, it seems to use a 512-bit modulus, which is, to say the least, a bit short... but OK for test. In your case, one must assume that whatever is your server application which uses OpenSSL, it has configured the library with a 768-bit modulus. It is possible (but it depends on that application) that stuffing explicit DH parameters in the same file as the one containing the server's certificate suffices to force OpenSSL to uses these parameters.

Notes:

If OpenSSL, as a server, selects an "export" cipher suite then it will force use of a 512-bit modulus for DH, but this is an edge case.
You are not completely free to use any size you want because of interoperability issues. It seems that some SSL clients out there will not like a DH modulus longer than 1024 bits. I also surmise that a DH modulus size which is not a multiple of 32 or 64 may induce extra problems.
With Elliptic Curve DH (the recent ECDHE cipher suite) the problem is different, because most implementations support only a handful of specific curves, not "any curve of a given size". There is an extension which allows the client to tell which curves it supports; otherwise, the server will choose depending on its configuration (in any case, anything else than P-256 will imply interoperability issues).


By how much does the addition of a salt slow down a rainbow table attack?

If you want to built rainbow table for a list of salted passwords, you need to do so for each possible salt value. If the length of the salt is sufficient and if the salts are picked up correctly (i.e. never reused), then it pretty much makes rainbow tables useless.

Basically, if you have n bytes of salts, it increases the necessary operations and storage for building a set of rainbow tables by 2^n


School asked us to submit our MAC addresses

I think you should ask why they want to use the MAC address, not necessarily for privacy reasons; "why do you need the MAC Address?" I think it's a reasonable question to ask them.

Firstly, they will have MAC addresses of all the individuals who connect to the WiFi. Any device connecting to the WiFi will reveal their MAC address, based on the ARP protocol.

They may think locking down WiFi to known MAC addresses is a good security measure. It's not really because I can obtain your MAC address if both of us are in the same Starbucks and on the same WiFi. I can then spoof your MAC address quite easily. So from a security measure this is not great.

They may want to track your activity. They can do this already without asking for your MAC, just giving them the MAC address allows them to map it to a individual easier. They can get a history of MAC & IP address from logs and  their NAT can keep a history of IP Address & Ports and map back to the MAC address.

If you use Tor, they will be able to say you used Tor, but not the content.

So, I would ask why do you want my MAC address, giving out the MAC address is not going to really affect you. Unless of course on your home WiFi or something else you are using MAC address as a method to identify yourself; as MAC address can be easily spoofed.


Isolating Web application hosted on same web server

If you have multiple websites on the same server then depending on the issue, a security problem with one site may well affect another.

Mitigating this essentially means increasing the separation between the two applications.  You could do this by using somthing like a chroot jail or if that's not enough isolation you could look at using VM guests on the same host to provide more isolation.


Multiple problems here:

This setup would force putting the secret key on the client.  Anyone with decent reverse engineering skill could retrieve it, and then they reproduce all requests at will.
There's no point of putting things like 'desired_object_id and such in the hash, if all these pieces are visible in cleartext (the URL).  The only reason to do this is preventing the attacker from finding your secret key.  But the easier prevention method here is to just simply pick a good (high entropy) secret.
Timestamp is the weakest form of a nonce.  If you need to reproduce the timestamp on the server end, then you are forcing all the clients to have well synchronized clocks.  If you're using it merely for a nonce, then you're failing to recognize an important property of nonces:  they have to be random.  Timestamps aren't random, even if the clocks are sloppy, they're going to be within a day (86400 secs per day), out of the possible 32bit (4.2 BILLION seconds), which is utilising a tiny fraction of the possible keyspace, and it's not even randomly spaced, they're clumped all together around a value you pretty much know (current time).


Are all (or most) expired certificates issued by 3rd party certificate authorities also marked as revoked?

Note that the following is only valid for the usage of certificates in the context of TLS. It can differ in other use cases for certificates, like with digital signatures on documents, mails, signed programs etc.

You don't have to revoke a certificate even if you renew it. You need to revoke a certificate only if it or what it represents got somehow compromised, like if the private key might be known to some third party or if the domain has changed the owner and thus all previously issued certificates to the old owner should be no longer valid.

Otherwise a certificate has an expiration time where it will be naturally stop working. Proper clients will check the expiration and will not accept certificates which are expired. No additional check for revocation is done for expired certificates since they are not valid anymore anyway and thus no revocation need to be done.


Is it possible that my home ADSL router firmware was hacked?

Probably not hacked, but your ISP seems to use some kind of DNS redirection to make some additional money (especially if you are beeing redirected when you type in a wrong adress or something like that).

You should be able to change the DNS the router uses, simply switch to a alternate DNS like OpenDNS (http://www.opendns.com/)


Whether this is a good or a bad idea depends on what kind of password this URL password replaces.

An URL is a usually a fairly long string; the example string is 46 characters long. This makes a simple brute-force attack (e.g. try every single combination of letters, digits and special characters) infeasible and an url like the above one is thus a much better password than one that consists of just a string of 6 fully random letters, digits and special characters.

The above URL is also a better password than the ones that are generally posted in "the ten million most common passwords" etc. The example URL contains at least 4 words - w3schools, sql, injection and asp. Them being dictionary words isn't really a problem. If each of these words was chosen randomly out of a pool of, say, 10000 possible words (this is a lower bound; there are way more than 10000 available domains and many more than 10000 words - this includes the URL of this question, which includes the id '143283' - so that's a million possibilities right there), you'd have a password equivalent to about 53 random bits. That's not including any special characters (e.g. where the slashes and underscores are, which would add a few additional bits). 53 bits isn't safe from brute forcing any more, but it's way, way better than most passwords users select (123456, password, loveyou, Maria, EatMyBackside and so on). So you might be safe simply because other passwords would be cracked before yours (you don't have to run faster than a lion to escape him - you just need to run faster than your peers...)

Now to the problems: The first one is that an URL is, contrary to what you say, kind of personal information. In order to use the URL, you need to know that it exists, e.g. you must have visited it at least once. This is information that could be extracted from sources other than you; for example, if your browser history was captured, chances are good your password URL would be part of it. Someone might also arrive at the URL (or at least at part of it) by eavesdropping on your web browsing and looking at which sites you visit. It would then be a simple job to have a spider crawl all the valid urls on these sites and feed them into a password guesser.

The second one is that while the space of all URLs is fairly big, it's not as big as you'd think. Also, not all domains are equally likely to be the source of your password URL; for example, it's a fairly safe bet you know reddit and craigslist and stackexchange, but that you've never visited the website of the university of Vienna. So even if I can't get at your browser history, and even though I can't check every single URL out there, I can still select likely domain names (say, the 50000 most visited domains) and crawl them, thus increasing my chance that I'll find your password.

The third one is that the math I did to arrive at the password size of 53 bits assumes that the words found in an URL are unrelated and chosen randomly. As you can see with your example URL, the words w3schools, sql, injection and asp are hardly unrelated; they all belong to a cluster of words having to do with the web. Many urls will sport such words taken from a word cluster, thus further reducing the number of combinations I have to try.

So, no, an URL is not a good replacement for a secure password (e.g. a very long one with a strong random element). But still, it's much better than your basic six-letter dictionary word.


How can "USB stick" online identification possibly work?

What your bank gave you is an USB security token with a digital certificate (like these). These are standardized hardware devices which almost every operating system supports plug&play out of the box. They are very common for implementing multi-factor-authentication to high-security systems in enterprise IT.

Your web browser uses HTTPS with client-based certificates to access your bank's website. It uses your operating systems certificate store to find an installed certificate which matches the identity the webserver requests. When you have a standard USB security token installed, the operating system will also look for any certificates on the token.

The operating system can not do the verification process with the webserver by itself, because the token doesn't allow to read the private key of the certificates stored on it directly. The token includes the hardware to do the verification. So the private key never leaves the USB stick. That means even if your PC is compromised by malware, the private key of the certificate isn't in danger of being stolen (but keep in mind that this method doesn't provide any protection after the authentication was successful. Malware can still screw with your web browser).

By the way: Which bank is that? If my bank would also support this authentication method, I might even start doing online banking.


Let's look at them in turn.

Remote Access.
Secure enough if you do it properly, usually not considered because it is the most expensive option and it really has no advantages over other options if you aren't doing anything fancy.

Native client with secure networking built in.
Secure enough if you do it properly, but it requires you to write security code, and you don't know what you are doing, so a bad idea.

Web client.
Secure enough if you do it properly, but it requires you to write security code, and you don't know what you are doing, so a bad idea.

Establish VPN link and run an insecure client.
This is one you left out. Secure enough if you do it properly, not terribly expensive, only slightly less convenient for users, sounds like a winner!

Note that although I have dismissed options 2 and 3, I have only done so based on the threat model you describe in your question, which may well be wrong - for example you are assuming the bad guys are all outside the network perimeter.


When using symmetric key encryption, do we need to sign?

Encryption with a secret symmetric key does not prove authenticity unless you use an authenticated encryption mode of operation such as GCM. Authenticated encryption algorithms generate a Message Authentication Code (MAC) in addition to encrypting the message, and if the shared key is properly secured this can be used to prove the authenticity and integrity of the message but not non-repudiation (this is a big "if" - more later).

Regular symmetric key encryption with a shared key does not prove the integrity nor authenticity of the message because nothing prevents an attacker from generating a random message which the receiver will then decrypt and accept. Though the attacker doesn't know what the decrypted message will look like there are many situations in which having the receiver accept a randomly generated message may be advantageous to an attacker.

Only someone with access to the symmetric key can generate a MAC of a message, so using authenticated encryption with a properly secured symmetric key is enough to authenticate the message. MACs do not provide non-repudiation because in symmetric cryptography the receiver also has the same secret key, so there's no way for the receiver to prove that the sender and not the receiver signed the message.

As emphasized previously, using a shared key for authentication requires the shared key to be properly secured. Specifically, if the receiver generates the symmetric key and sends it to the sender asymmetrically encrypted with the receiver's public key (which is the ordinary way to send encryption keys using PKI) then this symmetric key cannot be used to prove the authenticity of messages sent by the sender since nothing in the process proves the identity of the sender. Anyone with access to the receiver's public key (which is after all public) can generate a random symmetric key and encrypt it with the receiver's public key.

A symmetric key can be used to authenticate a message only if the scheme for generating the shared symmetric key includes two way authentication. Schemes which include two way authentication to generate shared keys for signing and encrypting messages are commonly known as a Secure Authenticated Channel or SAC.


Is HTTPS required for PCI Compliance when downloading desktop software patches, if no PII is transmitted, and content is digitally signed + verified?

As per my knowledge, https is not required if Card data is not present.

Thanks


Are the following two ways to obtain server certificates for web servers to host web applications?

No, they are not the same.

What does certbot do?

certbot is a program by the EFF, which automates the certification process. The command you posted generates a certificate signing request (CSR) for the domains your_domain and www.your_domain. The servers of Let's Encrypt then try to contact your instance of certbot via those domains. If successful, this proves that you indeed own those domains and are thus eligible to generate certificates for it.

It furthermore automatically configures nginx to serve via HTTPS and use these certificates. These certificates will be accepted as legitimate by all modern browsers.

What does dotnet do?

dotnet generates a self-signed certificate. These are useful for development purposes, where you don't expect someone to attempt and spoof your connection. Most likely, you'll connect to localhost anyways.

As a result, while those certificates are indeed real certificates you can use to test your HTTPS configuration, all browsers will warn you that these certificates are not trustworthy. You can either ignore these warnings, with some browsers even allowing options to ignore untrusted certificates on localhost (e.g. Chrome's allow-insecure-localhost flag), or you can manually mark this certificate as verified.

Of course, the purpose of such certificates is debugging and testing. You should never use such certificates in a production environment.

Do these work on web servers or web applications?

The task of a web server is to handle the incoming connections, parse the HTTP request and then pass it on to the web application. The server is therefore the one that handles TLS stuff, such as which TLS version to offer, and which cipher suits to offer.

You could, in theory, let a web application do that, but why would you? The application focuses on what a user does, not on the technical nitty gritty of the connection.

Can the two be swapped?

Yes. certbot and dotnet aren't bound to Ubuntu. You can use each application as you see fit for your use-case, as described above.

Can I have a tl;dr?

Sure. certbot generates a production-ready certificate, but requires an external domain. dotnet generates a self-signed certificate for development. This one is not for production use, but can be generated on your own.

Your web server is what handles all certificate and TLS stuff. Your web application is what handles the logic. It's completely agnostic whether or not it's called via HTTP or HTTPS.

You can use either certbot or dotnet, or even openssl to generate a self-signed certificate. The choice is based on what you need from a certificate.


I don't have much experience with AWS, but if your main goal is to protect against web-related exploits like XSS, SQL injection, etc., then a web application firewall may be more effective. Snort certainly has rules available for these things, but in my experience a web application firewall will do a better job. This thread has a good explanation on why this is often the case: Using an IPS as an alternative to mod_security

If you are using apache mod_security is the most popular WAF. For DDoS and brute force protection, check out mod_evasive.

Of course Snort does a pretty good job as well and protects against things that WAFs do not, so if the extra resource usage doesn't concern you then I don't think there's any harm in also running Snort as an additional layer of protection.

Ultimately though, the best way to secure a web application is to audit the web site's source code to make sure that these vulnerabilities don't exist in the first place. IDS and web application firewalls are great, but if your site has a vulnerability, a determined attacker will find a way to exploit it.


A plausible hypothesis is the following:

The spammer optimizes his spam-sending by grouping targets from the same domain: when a spam must be sent to userA@example.com, userB@example.com and userC@example.com, then the spam software sends a single email to the incoming SMTP server of example.com, with the three addresses as recipients. Email grouping is good for bandwidth, and this benefits the spammer as well.
The spam themselves are sent through a botnet, so they seem to come from "the whole planet" with no single source.
The spammer has collected a lot of addresses, including the addresses of these two users, but none other. Why ? Because neither of the two users got his machine compromised in any way. It is someone else, completely outside of your organization, who installed malware on his machine; and that third person, that you don't know and over which you have no control, had the two users' email addresses in his address book.

It is an unfortunate property of spamming that you get spammed because of the sloppy behaviour of other people.

Don't forget, too, that spammers are not necessarily good at what they do. I regularly receive weird spams: empty messages, spams whose text contents is "%INSERT_RANDOM_CONTENT", hundreds of copies of a single spam... A lot of wannabe spammers appear to have difficulty using their own spamming tools. As usual, incompetence is a driving force of the Universe and explains a lot of the observed weirdness.


Security Risk of Disabling forceguest in non-AD Environment

I believe this answers your question: http://www.microsoft.com/technet/security/advisory/906574.mspx

  Windows XP mitigates several security vulnerabilities by preventing users who do not have a valid logon credential from accessing the system remotely. An example of this is the vulnerability that is addressed in Microsoft Security Bulletin MS05-039. However, when you enable Simple File Sharing, the Guest account is also enabled and given permission to access the system through the network. Because the Guest account is a valid account when it is enabled, and is given permission to access the system through the network, an attacker could use the Guest account as if they had a valid user account.


Requiring e-mail from user when using ASP.NET Identity password reset features

I'm not familiar with this exact framework, so this is generic security advice, but: The correct way to handle password reset flows (with a token contained in a URL that the user is emailed, and then clicks), is for the token itself to be used to look up the user. You don't need any other way to identify the user (the token is unique for every user, and indeed for every password reset attempt, of course).

It is a very bad idea to even have some other way to identify the user who is resetting their password, because if you do that, you open yourself to the risk of an attacker entering somebody else's email address (or user ID, or name, or whatever) and resetting the other person's password instead. To prevent that, you would need to confirm that the token from the link is the current password reset token for the indicated user, and if you can do that, you can identify the user from the token directly and there's no need for the user to supply the identity. Passing the identity in the URL is not any safer; an attacker can modify the URL before loading the web page just as well as they can lie about their identity in a web form.

If there's no way for the server to look up a user from their password reset token, then frankly that is an incredibly silly bug and should be reported and/or patched (if open source) immediately. A bug like that would make me seriously question the quality of the entire authentication codebase.

EDIT

The possibility that the requirement exists to provide additional security occurred to me, but I didn't include it in the answer initially as it seemed unlikely. It should be completely impossible to brute-force the tokens; they should be minimum 128 bits of securely-generated random string, with a lifetime measured in minutes (single-digit hours at most) before use and expiring immediately upon use. That leaves only ways for an attacker to capture the token before it is used, and there are mitigations to all of those vectors:

Attacker captured the victim's URLs (perhaps in a proxy log or similar) and manages to use the token to reset the victim's password before the victim can do it themselves. The odds of this ever happening in a situation where the attacker couldn't also determine the victim's email address is pretty minimal (as it implies that the attacker is able to view the plain text of the victim's HTTPS traffic).
Victim clicks the link then walks away from their computer before completing the password reset, without locking it, and the attacker sits down in front of the machine. This both involves a level of "user is being incredibly foolish" (and you know what they say about making something idiot-proof), and the attacker could just go look up the victim's email address (they're sitting at the computer where the victim just clicked the link!) in the event that the attacker didn't already know it. This attack is more properly mitigated by making the password reset page itself have only a very short lifetime (it should not take more than five minutes to enter a new password, max, even assuming the user is disabled and must use a really slow input system).

There is an argument for, in extremely paranoid situations, protecting against the first case by accepting the cost of user hassle and taking the risk of insecure implementation. For the most part, it seems like a clear net negative in utility. The second case doesn't even really bear mentioning because the "protection" of requiring the identity is trivially bypassed. Unless there's some other scenario I'm missing, this provides negligible benefit.


Basically, HSTS allows a site to store a flag (true or false) - in other Words a bit, in a web browser.

Storing HSTS super cookies are accomplished in this way:
Lets say we want to store the value A, binary 01000001.
We can then store this as by redirecting the user to a series of websites, like
https://00.example.org indicating HSTS=off
redirecting to:
https://01.example.org indicating HSTS=on
redirecting to:
https://02.example.org indicating HSTS=off
...
...
redirecting to:
https://08.example.org indicating HSTS=on

"Reading" the cookie is simple as redirecting user to:
http://00.example.org
If HSTS is on, the webserver will receive a request to https://00.example.org, else http://00.example.org
redirect then to http://01.example.org
and so on.

The misdesign in HSTS is that the browser should "correct" a HTTP visit to HTTPS automatically if HSTS is enabled. A better idea would be that a HTTP request to a HSTS resource would instead fail completely with no recourse from the user other than manually typing https Before the url. But such things might endanger the usability.

No you dont need to worry. A site that wants to track you could aswell store your IP adress on server side to be able to show targeted ads and such. If you want to surf completely anonymously, for example via TOR, you should turn off HSTS completely, and instead itself be vary of SSLstrip by manually checking that HTTPS is being deployed.


Please try to avoid RewriteRule. It is a best practice to implement security rule from the top. In this context it is httpd.conf. I am assuming that password.txtlocated in the apache root directory.

<DirectoryMatch ./password.txt>
   Deny from all
</DirectoryMatch>

If any users access that file then s/he will get HTTP 403 - Forbidden error
You can also redirect the user to another page like 404.html. Use below to redirect user.

AliasMatch ./password.txt /404.html

Moreover, if password.txt file is not being used by HTTPD process then revoke permission HTTPD process owner's all permission from the file.


How could malware like Stuxnet be detected?

I can think of some ways:

Malware connect to C&C server. if you monitor your traffic (as sensitive system should be monitored) - than you find unusual traffic that can be sign (and should be investigated)
If the malware uses USB flash drives to spread itself, and you have different computer platforms in your environment (e,g: windows, mac, linux and BSD systems), than you will see other platforms executables on the flash drives. This way you have a real "sample" of the malware to analyze. (most malware are platform specific), so you can see the malware files if you connect the flash drive to a non-windows machine without the risk of being infected)
Honeypots - You said that stuxnet is too smart to fall in honeypots, but I think that it all about who is smarter - the honeypot or the malware. If you use a common honeypot - the malware will ignore it for sure, but if the honeypot is using new techniques - it will not be detected as one by malwares.
keep in mind that some highly sophiticated malware, like Duqu and Flame, do spread only when instructed by C&C servers, that makes them much less vulnerable to finding by honeypots.

After I wrote this, I went to see how Stuxnet was found, Stuxnet itself was detected because of a bug who made BSOD (Blue Screen of Death) on infected computers (source). Flame was found while researchers were looking for another malware. I couldn't find how Duqu was found.

So we can all be very clever, but what we really need to find such sophisticated viruses is luck...


Does a simple mobile REST API need HTTPS?

Do you care if a 3rd party monitors or modifies a request in transit from the client to you or from you to the client?

If you don't care, just use HTTP. If you do care, use HTTPS.

Is there a way to inject some malicious questions if simple HTTP is used? Absolutely, the real question is does it justify the extra cost of developing a HTTPS system to prevent that from happening? (most of the time the extra cost to implement HTTPS over HTTP is so minimal the answer to the question usually is "yes, the cost is justified")


How Google has an SSL certificate from itself and my browser doesn't give an error

Google has its own intermediate CA. They have a webpage here https://pki.google.com/


With Google's new Privacy Policies going into effect soon, how can I better protect myself using their services?

The "privacy policy" of Google, and hackers, are mostly orthogonal issues.

The new privacy policy is about making clear to you, in a legal way, that Google may aggregate all your data, regardless of the "service" under which you made such data available to Google.

The "hacker risk" that you allude to is more about how a malicious individual, obtaining an illicit access to some of the machines within the Google network, could escalate that access into access to more machines within the Google network.

The only link between these two themes is that, in order to aggregate data from several services, the machines which host these services must be somehow linked together and let the data flow. However, it is highly probable that all the machines at Google's are already linked together with high data flows, if only to mutualize infrastructures, maintenance and backup tasks, and your data already flows quite freely. The new privacy policy is not about instituting new data flow processes; the data is already gathered and moved around. The new policy is about making it legal for Google to have a look at the gathered data.

Therefore, the new policy is unlikely to increase, or decrease, or alter in any significant way, the resilience of Google's systems to external malicious hackers. What the policy changes is that it allows Google itself to do some data mining and matching that would otherwise be considered as "bad".

(Presumably, Google is not evil -- if Google is evil, we are all doomed anyway.)


A government agency sent our website admin an email that our website had been defaced

It's extremely easy to fake email.  If someone did fake this, I don't see how the agency would know about it.  The concern is that the link they sent you was the attack itself.  For example, this could be a CSRF attack:

  With a little help of social engineering (such as sending a link via
  email or chat), an attacker may trick the users of a web application
  into executing actions of the attacker's choosing.

One suggestion is to contact the office and find out if this is something they do.  Just because the language seems right and says it's from the right sender means nothing.  That's a common approach used in phishing emails.


How to protect API Key in Android application

So, you're asking if you can store the API Key in the App, but also protect it from being stolen? This is not possible.

There is a possible solution to make theft more difficult. Use OTP XOR encryption so that the API Key is split into two parts that must be combined.

The first part is stored in your application.

The second part is downloaded from your server equipment and then stored in the App-Private data, preferably in such a way that does not make its purpose obvious. Alternatively, you could 'not store' the second part, (keep it in Application Memory or Intent Extras only) but then you'd have to download it from the server every time the app is launched.

Then you can use Progard to make the overall application more difficult to understand.

Of course these only make theft more difficult, and do not actually secure the Key from theft.

If you really need to secure the key, then you'll have to route all requests to the Google Maps API through a Proxy server which you control. That Proxy server can add the API Key to each request as needed.


New Gmail login system—going against conventional wisdom?

For smaller sites, you don't want to allow hackers to enumerate your user lists, but for Google, the site is so large, one can assume almost everyone has an account or several accounts. So, the risk is minimized after a threshold of ubiquity.

It is still a good idea for most sites to not disclose whether a username exists, but the risk needs to be weighed against the new user registration process. What you want to prevent is an automated process from enumerating your lists. The new user registration process should include some form of delay or gate so that a script can't rapidly try a dictionary of users. This is often achieved by sending an email with the results of the un/successful registration process. Yes, one could still enumerate, but there is a delay and an additional step.

Another thing to consider is the difference between a public site and a private site. Google is a public service an usernames are also public (disclosed with every email sent by an account). On the other hand, an internal corporate site, where only current employees can access, is private, and requires more stringent controls to prevent enumeration.


what is the difference between a mac and a digital signiture

In both MAC and digital signature schemes, you have two algorithms:

Generation: given the message m and a key K1, compute the MAC value or signature s.
Verification: given the message m, a key K2 and the MAC value or signature s, verify that they correspond to each other (the MAC value or signature is valid for the message m, using verification key K2)

With a MAC, keys K1 and K2 are identical (or can be trivially recomputed from each other). With a signature, the verification key K2 is mathematically linked with K1 but not identical, and it is unfeasible to recompute K1 from K2 or to generate valid signatures when you only know K2.

Thus, signatures dissociate the generation and verification powers. With a MAC, any entity who can verify a MAC value necessarily has the power to generate MAC values of its own. With signatures, you can make the verification key public, while keeping the generation key private. Signatures are when you want to produce a proof verifiable by third party without having to entrust these third parties with anything.

Application: a CA (like Verisign or Thawte or whatever) issues a certificate to a SSL server. Everybody, and in particular your Web browser, can verify that the certificate issued to the SSL server has indeed been signed by Verisign/Thawte/whatever. But this does not give you the power to issue (sign) certificates yourself, which would appear as if they were issued by Verisign/Thawte/whatever.


DNS settings compromised from WAN on Edimax ADSL router

In security practices we try to patch the vulnerabilities. But if the patches are not available, we try to make attackers life hard by things like isolation.

There are huge problems with WAN Management in routers these days,
you should disable it, if you really do not use it. Unlike modern OSes,
patches for router OSes comes very hardly.
Many ADSL routers provide built-in firewalls in these days. Make sure Incoming Default Policy = Deny.
Limit WAN access IP if possible in your router and go to some
different port for accessing console, if supports.
If your router supports you can try Open WRT like firmware/OS which
has relatively good patching cycle.


How do i use a guessable ID for authentication

Given your premises, the problem cannot be solved in the form you want it to.  You have said that (1) the device ID is guessable, (2) the device ID is the only secret that you want to allow us to use, (3) you want to authenticate using the device ID.  Well, that's not solvable.  If I can guess Alice's device ID, then I know all of the secrets necessary to masquerade as Alice, and your system won't be able to distinguish me from Alice.

You mention something about encrypting with a cryptographic key, but if you had a secure way to share the cryptographic key with just Alice (in a way that prevents me from learning it), you could simply use that key for authentication -- you wouldn't need to use the device ID.  However, this is ruled out by your rules that no other secret is permitted.  So I don't really understand what you are asking or what are the real constraints here.

Why don't you tell us about the application domain and what you're trying to achieve and why you think the device ID is the only thing you can use for authentication.  We may be able to come up with some approaches or solutions that haven't occurred to you.

For instance, here is an approach you could consider.  When the device first registers itself with your service, it generates a new, unique public/private keypair, store the private key on the device, and send the public key to your central server.  There might be some secure registration procedure where the public key is sent to the central server and registered and associated with Alice's account.   In the future, when the user wants to sync on a machine and invoke your central API, the device can set up a secure connection to your central server and authenticate itself using its private key (think client certs and SSL), then send those API calls.  The encrypted communication can be routed through the machine/desktop, so that it does not require trust in the machine/desktop.  The private key would never leave the device.  Please note that this is just an example of a possible approach -- depending upon your requirements, it might or might not meet your requirements.  Please don't get too caught up in the details of this particular example.  Rather, the point I'm making is that if we are clear on your requirements and constraints, we may be able to come up with some suggestions about the best way to solve your problem, within the constraints you face.


Using sudo to secure git deployment via web script

Calling sudo from apache just doesn't sound right, despite the fact that I can't put my finger on the exact set of reasons why it would be a bad idea.

I would suggest instead of doing sudo to just run a very simple CGI as "suexecusergroup deploy" that would receive the postback from bitbucket and perform the git commands. This is a lot more straightforward and sane.


Can a malicious computer on a link local network cause harm on another network?

A virus is just a computer program. If Computer A can communicate with Computer B by any means, a virus on Computer A can reach Computer B. Reach, not necessarily infect.

To a virus infect Computer B, it must use a vulnerability, usually remote code execution. On a network where all computers share the same OS version and the same group of applications, usually infecting one computer via network is enough to infect all others.

If the firewall allows traffic from link local to the other network, any virus on Computer A have the possibility of reaching Computer B.


If the site is not loaded in the frame, is the site vulnerable to click jacking.

For Click jacking to occur the site should be fully loaded in the frame,only then click jacking is possible,which means you can successfully load the attacker's website into the victim's webpage in which he is currently using.

So if text is only displayed and the site is not successfully loaded, does that mean the site is not vulnerable ?

If the text is displayed and the site is not successfully loaded then there is no click jacking vulnerability


OWASP Recommendation on Client-Side Password Hashing

By storing a staled hash of the password and then using this same hash as an authentication token,  an application is more vulnerable to attack because this application is now storing authentication credentials in plain-text.   An attacker can use SQL Injection to read this hash and then authenticate without having to crack the hash to obtain the plaintext password.

The OWASP wiki entry refereed in this question was misleading and was removed:

  Here is how the salted MD5 technique works: the database stores a MD5
  hash of the password. (MD5 hash is a cryptographic technique in which
  the actual value can never be recovered.) When a client requests for
  the login page, the server generates a random number, the salt, and
  sends it to the client along with the page. A JavaScript code on the
  client computes the MD5 hash of the password entered by the user. It
  then concatenates the salt to the hash and re-computes the MD5 hash.
  This result is then sent to the server. The server picks the hash of
  the password from its database, concatenates the salt and computes the
  MD5 hash. If the user entered the correct password these two hashes
  should match. The server compares the two and if they match, the user
  is authenticated.

MD5 is not appropriate for passwords.  This is a broken primitive and a violation of CWE-916.   Even if this was describing a secure challenge response, HTTPS is a more appropriate tool and is required to protect the session id.


Is opening port 3389 on a router and forwarding this to a Windows SBS 2003 server secure?

By "open on their router" I assume you mean open to the Internet. I'd advise against this. Remote Desktop Protocol is susceptible to known attacks. Also you say "patched", but even as recently as last week Microsoft issued a security bulletin against RDP:

  This security update resolves two privately reported vulnerabilities
  in the Remote Desktop Protocol. The more severe of these
  vulnerabilities could allow remote code execution if an attacker sends
  a sequence of specially crafted RDP packets to an affected system.

I would strongly recommend putting some kind of security gateway (e.g. authenticated firewall, VPN...) in between users and the RDP service.


Should antivirus HTTPS scanning be left on? Is it secure?

~4 sources that will make you think twice about the security of AV TLS decryption:
Antivirus Software Weakens HTTPS Security: Researcher

“It seems strange that it turned into something people consider a
legitimate security technology. Filtering should happen on the
endpoint or not at all. Browsers do a lot these days to make your
HTTPS connections more secure. Please don't mess with that.”
ESET representatives said the company is aware of the issues presented
by the researcher.
The researcher reported that Kaspersky’s product is vulnerable to
FREAK attacks, in which an attacker can force clients to use weaker,
export-grade RSA encryption. This can be problematic considering that
Kaspersky intercepts HTTPS traffic by default for important websites,
the expert said.
“I also found a number of other issues. ESET doesn't support TLS 1.2
and therefore uses a less secure encryption algorithm. Avast and ESET
don't support OCSP stapling. Kaspersky enables the insecure TLS
compression feature that will make a user vulnerable to the CRIME
attack,” Böck reported. “Both Avast and Kaspersky accept nonsensical
parameters for Diffie Hellman key exchanges with a size of 8 bit.
Avast is especially interesting because it bundles the Google Chrome
browser. It installs a browser with advanced HTTPS features and lowers
its security right away.”

That was in 2015;
And:

Validating TLS certificates in non-browser software is the most
dangerous code in the world

See "DNS Over TLS" here: https://dnscrypt.info/faq or the source here.
Some Bitdefender products break HTTPS certificate revocation (Source):

If a website’s certificate has been revoked by a certificate
authority—for example, because it was issued fraudulently or because
its private key was compromised by hackers—affected Bitdefender
products will still accept it as valid. More importantly, as part of
their HTTPS scanning feature, they will convert the revoked
certificate into a certificate that local browsers will trust, despite
the fact that under normal circumstances those browsers would reject
the original certificate.

Ditch the HTTPS Scanning feature of your antivirus (Source):

Users might be vulnerable while accessing secure HTTPS websites, and
their antivirus is to blame. A thorough research, conducted by experts
at Mozilla Firefox, Google, Cloudflare and three American
universities, shows that several popular antivirus software
“drastically reduce connection security” and expose users to
decryption attacks. This isn't new by any means and the HTTPS
interception technique used by anti-viruses has been the subject of
debate for several years.
And here's the problem: Security software vendors are poorly handing
inspection after the TLS handshake, according to the researchers.
They’ve looked at eight billion TLS handshakes generated by Firefox,
Chrome, Safari, and Internet Explorer, with antivirus software on.
Researchers have analyzed Firefox’s update servers, a set of popular
e-commerce websites and the Cloudflare content distribution network.
“In each case, we find more than an order of magnitude more
interception than previously estimated,” the paper reads. They found
interception happening on four percent of connections to Mozilla's
Firefox update servers, 6.2 percent of e-commerce sites, and 10.9
percent of US Cloudflare connections. What’s worrying is that when
intercepted, 97 percent of Firefox, 32 percent of e-commerce, and 54
percent of Cloudflare connections became less secure.
“As a class, interception products drastically reduce connection
security. Most concernedly, 62% of traffic that traverses a network
middlebox has reduced security and 58% of middlebox connections have
severe vulnerabilities,” the report reads.
Not only do security software reduce connection security, but also
introduce vulnerabilities such as failure to validate certificates.

That was in 2017,
The large attack surface and many variables of TLS stack like TLS cipher suite/false_start/secure negotiation, session identifiers, RTT-0, downgrade protection, Privacy oriented OCSP Stapling/public key pinning, and other parameters may be broken, downgraded, modified or unavailable by AV TLS and replace specifications of the browser. To be as secure as a browser, all these security mechanisms must be included, and kept up with the times, which is something dedicated web-browsers excel in. It would be best if they could detect and mimic browser settings. HTTPS interception also affects non browser connections. Hopefully they have and will continue to improve rapidly, but the "most dangerous code in the world" is something I would be cautious with. Replacing hundreds of points of failure (one cert in place of hundreds) with one point of failure is risky. Cutting this out may be a necessary change home & enterprise environments to ensure malware is not inadvertently assisted by MITM AV or Middlebox AV. Better alternatives include cisco Encrypted Traffic Analytics: Detection without Decryption