What is the fight-back mechanism in OSPF?

OSPF is a routing protocol in which the various routers involved in the process periodically shout: they broadcast "Link State Advertisements" which tell the other routers how things look like in their own vicinity. The fight-back mechanism is the following: when a router observes a LSA which states falsehoods about itself, the router is allowed (and actually encouraged) to immediately send another LSA which sets the record right. It is a metaphor of the antique Agora: to counter liars, just stand in the Agora yourself and whenever you hear a lie about yourself, shout "this is not true".

This is not a very effective security mechanism. It is not officially a security mechanism either; the behemoth OSPFv2 specification does not contain the word "fight". Actually the specification deals very little with security (the "Security Considerations" section is only half a page, for a 244-page specification). This draft is a more thorough security analysis of OSPF; see in particular sections 4.1.3 and 4.1.4 which explain how to circumvent the fight-back mechanism or even turn it into a tool for disruption (in the Agora metaphor, you may use the fight-back to create an ear-shattering shout contest which drowns normal conversation).


VPNs neither leak DNS nor do they inhibit DNS leaks. A VPN is nothing more or less than an encrypted connection to a remote network. What you do with it (DNS, browsing, etc) is totally up to you and your configuration. In other words, whether or not DNS information goes thorugh your VPN depends on how you've configured your computer to use that VPN link.

A "Full Tunnel" VPN, which is where you configure your workstation to send all of your Internet traffic through the VPN, will not (cannot) leak anything.

Whether or not you're doing full-tunnel or split-tunnel isn't a feature of the VPN, though, it's determined by your own computer's configuration and routing table.

Note that this "Ultrasurf" thing where you reconfigure your browser to use a proxy address is not a VPN. It's a proxy. And proxy servers are not VPNs.


Here's how QapTcha works:

The JS creates a hidden input field and populates it with a random value.
When the user drags successfully, the JS posts that random value to a PHP script and clears the value from the form. It then creates a hidden input whose name is the random value.
The PHP script verifies that a session variable hasn't been set, and that the random value has been posted, and sets the session variable to the random value.
When the user posts the form, the script verifies that the randomly named hidden input exists.

This is kind of a neat trick, since it exploits the fact that most bots quickly fill out the form and don't parse/run JavaScript.

However, it's relatively trivial to bypass - we just fake the functionality of QapTcha completely. First, we grab the HTML of the page. Then, we send a POST to the initialisation PHP script, containing the random value. Finally, we send the POST with the random empty field set. Bam!

This is somewhat of a security-through-obscurity captcha, because any bot that knows about it can bypass it. However, it's reasonably safe to assume that it'll stop most non-targeted "drive-by" attacks, until QapTcha is prevalent enough to be worth bot developers' time.

An extension of this idea is the zero user interaction captcha, which, instead of testing the user, tests the browser. It tests whether the browser can properly use JavaScript, Flash, CSS, etc, and polls for mouse movement and keyboard presses. This data is sent with the form's POST, then analysed. For each test that is passed, the score is increased. If the score fails to reach a minimum threshold, action is taken, e.g. block the action, place in moderation queue, present with an image captcha, etc. There's also a trick using CSS where an input box is z-ordered behind other elements, which a user would never fill in but a bot would. There is a working example of this scheme somewhere, which someone presented at a talk a few years back, but I can't find it right now.


RCP and RAP applications are typically built using the Eclipse E4 Tool package. There may be test cases unique to the target underlying operating system -- Eclipse runs on OS X, Linux, Windows, and a few other OSes. First, get the Delta Pack -- http://download.eclipse.org/eclipse/downloads/drops4/R-4.4.2-201502041700/#DeltaPack

The Delta Pack contains all the platform specific resources from the SDK and is used for cross-platform exports of RCP applications. If you know how to install new software to Eclipse ("Help", "Install New Software", "Add"), then put the following into the Location field:

  http://download.eclipse.org/e4/updates/0.17

After you have a stable platform and know how to create and modify RCP and RAP applications using E4 and the surrounding technology tooltips, you are on the way to know how to pentest these apps. Many will affect Eclipse only and few will call out to a file on the operating system or a network. If they do, you can leverage many existing Java-friendly pen-test tools such as Javasnoop, JDB, JSwat, DSer, untidy (for XML), et al.

The closest thing I can find to a RAP application would be something like Oracle Forms. Here is a blog post describing three ways to target an Oracle Forms app that uses HTTP or TLS. The blog does recommend Javasnoop for other more-flexible tasks. Here are additional use cases for Javasnoop:

http://streetburnerbux.blogspot.com/2013/08/intercepting-traffic-from-java-based.html
http://streetburnerbux.blogspot.com/2013/08/hacking-java-apps-by-javasnoop.html
http://fixulate.blogspot.com/2012/09/java-attach-instrumentation-api-for.html
http://fixulate.blogspot.com/2012/10/java-instrumentation-agent.html

For the non-Java portions of a RAP pen test, such as Javascript, you may want to look at retire.js (a tool similar to OWASP Dependency Check that can be used to analyze third-party Javascript components for well-known vulnerabilities) or Fortify SCA (a good securtiy-focsued static-analysis engine that works on Javascript code).


The comments on your question seem to be rather misleading, or almost irrelevant. I'd ignore them if I were you!

Remember, upgrading the session requires establishing of a new communications session, it doesn't just take over the existing socket.

This looks like the classic scenario of binding to the wrong host or port. For the upgrade to work in the scenario you describe, your firewall needs to forward port 4433 to your attacking machine. If it doesn't, then you simply won't get your reverse connection.

If you have configured your firewall such that the forwarded port is not the same as the one you're binding to, then you have to take another step. For example, if your firewall is configured to forward port 443 to port 4433, then you need to:

set LPORT 443 -- this tells Meterpreter to call back on port 443.
set ReverseListenerBindPort 4433 -- this tells Metasploit to bind to port 4433 instead of 443.

Unless you have a persistent listener for your initial shell, you can even reuse the same port.

Given that you're using non-standard ports, it could be the the remote firewall is blocking the outbound traffic as well.

I hope that helps.


You should specifically allow the IP address(es) that is allowed to access the resource and Deny everything else.

order deny,allow
deny from all
allow from [your ip address] OR Allow from 10.0.0.0/24

Depending on your network configuration, requests to the server from the internet may include public IP addresses. Routers typically only provide NAT from the LAN network to the WAN network, not the other way around.


Many switches and routers now have active anti-spoofing, either alerting on duplicates, or entirely blocking IP addresses which are on a port where that address should never be. This is the only sensible use I can think of.

I don't think in any instance it would be a good idea to shutdown of the stack when it discovers its IP address has been spoofed - that would lead to really simple denial of service attacks (the attacker could just increment their IP address through the entire valid range, thus knocking off all devices that do this)

When you say 'protect itself' - as @nealmcb said - against what? An IP spoof is not a direct attack against another network address, in fact usually it is used when trying to pretend to be the valid device, so shutting the real one down would make that much simpler for an attacker as well.


Can I use 2 factor authentication for shared accounts?

Shared accounts are themselves a bad practice, because you cannot know who is actually doing the access. Each "administrator" should have his own account, to which you would grant administrator privileges.

2FA is about using two authentication methods concurrently, working over two distinct categories. The categories are: "something you know", "something you own" and "something you are". Knowledge can be shared (i.e. two different persons may know the same password -- a bad practice, as I said above, but still feasible). The two other factors are intrinsically bound to physical individuals; for instance, if using a physical token ("something you own"), then that token can be in the hands of only one person at a time, which is the whole point.

Therefore, if you use two authentication factors, then at least one of them cannot be shared. It follows that 2FA is intrinsically incompatible, at a conceptual level, with a shared account. The consequence is that if you succeed in having a shared account, then you are not using 2FA (you might get a cheap plastic imitation of 2FA, but not the real thing).

Don't use shared accounts. Shared accounts are evil.


Google tries to figure out if you are a bot or not. If it's in doubt, it serves you a CAPTCHA to check. Exactly how this is done is part of Google's secret sauce, and I don't think they will tell you. But here are some ingredients I guess that they mix together:

Your IP: Has it been identified as a bot already? Is it a Tor exit node?
The resources you load: A simple bot does not load styles or images, since it does not need them. That is a tell tale sign that someone is not human (or, as JDługosz points out in comments, blind).
Sign in: Are you signed in to a Google account? Does that account appear to belong to a real person?
Your behaviour: A human scrolls down the page, moves the mouse around, takes some time between pushing down the mouse button and releasing it. A human does not click the dead center of the check box every time. All this could be mimmicked by a good bot, but it is not easy.
Your history: Google knows a lot of your browsing history. Bots usually don't have a browsing history.

Figuring out exactly why you need to solve the CAPTCHA sometimes, but not others, is not easy. I could imagine that a fresh virtual machine has a browser fingerprint - installed fonts, plugins, etc - that is very common and therefore fishy enough for Google to flag your for a CAPTCHA. If you are behind a proxy, perhaps others have used it as well for non legit activities.

That you don't get a CAPTCHA when you clean your cookies is surprising. I don't understand why - then Google knows very little about you and should assume you need a CAPTCHA to be on the safe side. Perhaps they do some advanced browser fingerprinting so they still know who you are?

Do note that all of this is speculation. If you want more speculation, have a look at How does new Google reCAPTCHA work?.


PHP security hacking question, may be more than just PHP

Your code handles the SQL insertion correctly. I have two guesses about the attack:

The attacker could have repeated the request several times, and your code doesn't check if it has already downvoted the post.
The attacker have sent a lot of downvote requests in a very short period of time, allowing him/her to exploit a time of check / time of use race condition.


How does this unsigned exe launch without the windows 10 SmartScreen warning?

Windows Defender Smart Screen blocks or allows applications based on reputation. The reputation can be either for the application itself, or for the certificate used to sign it. Usually developers sign their code so their Authenticode certificate can build reputation and they do not have to repeat the reputation building process every time they issue an update for their application.
However, an executable (whether signed or unsigned) itself can also build reputation, which seems to be the case here. Enough people have used this particular executable safely that Smart Screen is now confident that this executable is not malicious.


Is it possible to perform a XSS attack in the title/subtitle of a webpage?

Yes, it is possible.  It all depends on where the content is reflected in the markup, and if the content is escaped properly for the given context.
Your xss doesn't work in the title fields because it's not formatted correctly for the given context.  The markup for "aMessage" is in an element context.  Your XSS Payload is formatted for that context.  "aTitle" and "aSubtitle" are in an attribute context.  Your payload is not formatted for that context.

You have a couple of different options to get it to work:

See if you can get to an element context.  Try entering aSubTitle with a value like

  "> < /popup> < script> alert('xss'); < /script> < popup>

The resulting markup should look something like

  "< popup title="What ever you entered for title" subTitle="">< /popup> < script> alert('xss'); < /script> < popup> < /popup>

If the output is being encoded for an attribute context, try exploiting a javascript event to execute your payload.  For example:

  " onmouseover="alert('xss');"
  could potential cause your payload to execute when the user mouses over your content.


Protecting Session Authentication Tokens

No need for any encryption or HMAC or anything else fancy like that. Some things you need to think about, though:

The protection against brute forcing is entropy. Pick a random number from a large enough space and an attacker would need millenia to guess one right. OWASP recommends at least 128 bits.
Make sure to use a cryptographically secure PRNG go generate the session IDs, so that there is no pattern in the generated session IDs. If you use a bad PRNG an attacker can guess upcoming IDs based on previous IDs.
Since it is not directly related to the generation of tokens I will not go into any length about it, but make sure to think about things such as session fixation, the HTTP-only and secure flags, etc. OWASP has a good cheat sheet.


If you send a bitcoin payment to a seller, will they learn your IP address?

The receiver won't learn your IP, but a somewhat determined adversary could. (Of course, if the seller is an adversary, then they could.) This isn't a part of the protocol (there's no sender_IP field in the transaction), it is accomplished via listening in many places on the mesh network and doing statistics to determine the originating node of a transaction. Bitcoin unmask attack. No one knows you're the originator, unless they're watching many nodes in the network. The transaction, when first sent, is indistinguishable from a forwarded transaction; so the first node to see it will think the true sender is just forwarding from another node.

You don't want to run Bitcoin over Tor, because it would allow the exit node to arbitrarily confuse your client as to the real state of the external bitcoin network. It can do this because it is the middle man in the only link b/t the client and the outside world. Bitcoin over Tor attack. To understand how this can work even with bitcoin's POW system, consider that, since there is only one point of connection (the Tor exit node) b/t the bitcoin client and the rest of the network, it is trivial for the exit node segment the network, isolating the client from all legit nodes and all legit POW. The attacker can then run its own bitcoin node on the segmented network, making the only hashing power on the network that of the user (you) and of the attacker. To execute the well known 51% attack, all the attacker needs is more hashing power than you. (Given that most clients don't having hashing enabled at all, any amount of hashing the attacker wants to do would be sufficient, given enough time.)

To be clear, you can use Tor to proxy your browser. But don't use it to proxy your Bitcoin client.

If it's really a problem, and you're willing to sacrifice absolute control of your coins, I would recommend using a web client that doesn't require much info to register and doing so through Tor. That way the unmask attack only unmasks the web client's server, which has no way of tracing you since you access it through Tor. If you're not willing to sacrifice a little control, then I don't believe there is a totally anonymous way to transact in Bitcoin.


Can a mismatched server encoding on HTTP POST or GET result in a security issue?

Request from client to server

Assuming there are no vulnerabilities in the UTF-8 decoder on the server (e.g. overlong UTF-8 encoding or illegal UTF-8 continuation bytes) that could bypass a filter or other encoding routine I can't imagine any sequence that could be decoded to anything dangerous in itself. It is not like UTF-7 where a sequence such as +ADw- can bypass a filter or encoder as they don't understand the encoding.

This of course is assuming that the UTF-8 is decoded and then reencoded for other backend components that may be vulnerable (e.g. a backend process that decodes in UTF-7 could be vulnerable if the raw bytes are sent from the front-end).

Response from server to client

Again, if the client UTF-8 decoder is free from vulnerabilities itself this should be safe. This is assuming the client is interpreting the server response as UTF-8 encoding - I wasn't sure from your question whether the client sending UTF-7 was also expecting UTF-7 in the response. If this was the case then yes it could be vulnerable to XSS via unencoded tags passed from the server. If not then another thing that could throw a spanner in the works are browser plugins (e.g. Flash/Silverlight) but these would normally either get their input from the browser once the text had been decoded, or from the server directly (in which case your pre-condition of only reading in UTF-8 across the network would still apply).


how to do 2 way ssl authentication without using a self signed CA

The server certificate and the CA certificate used for authenticating your clients are two different things.

First, you need to have your server certificate installed (SSLCertificateFile and SSLCertificateFileKey). You should already have that.

At this point, you have your server presenting his certificate to clients.

Now, you need to generate a CA (self-signed) and tell your Apache instance that this is the CA you want to use for authenticating clients. (SSLCACertificateFile and  SSLVerifyClient require)

You just have to sign your clients csr with your newly created CA.

Cheers.


What can be done to prevent disruption of hardware in the event of a powerful solar flare?

Shielding can be used to some extent. A Faraday cage, an underground bunker... can do wonders. Usually, the power grid will suffer most from a solar flare, because it is all unshielded obsolete under-maintained hardware, stretched to the max and beyond by competing regulations and market forces, and more often than not plain incompetence. So you first defence against a solar flare is an UPS.

Ultimately, protection against solar flares is similar to protection against the EMP from a nuclear blast, which is discussed in this previous question. Solar flares have the special characteristic of hitting a whole hemisphere at a time (the "day" half of the Earth), so if you want to maintain critical infrastructure through redundancy, then you have to spread it all around the World, literally.

Even more ultimately, if the solar flare is big enough, then we are all dead, and the question becomes moot.


How to get a Windows 10 complete memory dump on demand?

Some time ago, Microsoft bundled quite a large collection of tools, some more powerful than anything available for Windows.

I'm able to log activity going on in the background that I've never been able to see up until that point. At any rate, if they haven't created icons for everything - which they shouldn't, find ALL the EXE files that lack any kind of icon - they're command line only, no GUI. Either cut and paste or create a copy of them and stick them in your C:\Windows\System32

For your immediate purposes, just find livekd64 (assuming your system is 64 bit? if not, use the plain livekd) and put it in `System32. It might help you acquire the dump information you're after.


Self-chosen fixed RSA PIN in addition to a Password

There are several configuration for generating the PIN. If the admin has configured it to OnDemand Authentication only via user PIN so you are getting the the token code via email/sms. But it can be configured for various other options.  You can make a suggestion to the Authentication Manager to change the PIN change policy for forcing the user to change the PIN after a fixed duration or include the both security question/password along with the PIN+Token code. The consideration taken is the for the lapse of security, no one will have access to both PIN and the token code delivery method with them at the same time. Which restrict the login attempt to just 3 for either wrong PIN or the token code.


If you set the permissions correctly, yes, you can be sure.

To grant user US1 select, insert, delete permissions to database DB1 use this query:

GRANT SELECT, INSERT, DELETE ON DB1.* TO 'US1'@'host';

or for all privileges

GRANT ALL ON DB1.* TO 'US1'@'host';

This way US1 can see and interact with DB1, while unable to interact with DB2.

You can test this by authenticating as user US1 and using the query: show databases; via the command line or phpmyadmin. You will only see DB1 in the results.


Is it safe to expose these particular Firebase derived services?

This may solve your problem !

<service android:name=".MyFirebaseMessagingService"
 tools:ignore="ExportedService">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT"/>
    </intent-filter>
</service>

<service android:name=".MyFirebaseInstanceIDService"
 tools:ignore="ExportedService">
    <intent-filter>
        <action android:name="com.google.firebase.INSTANCE_ID_EVENT"/>
    </intent-filter>
</service>

android:exported

  This element sets whether the activity can be launched by components
  of other applications — "true" if it can be, and "false" if not. If
  "false", the activity can be launched only by components of the same
  application or applications with the same user ID. If you are using
  intent filters, you should not set this element "false". If you do so,
  and an app tries to call the activity, system throws an
  ActivityNotFoundException. Instead, you should prevent other apps from
  calling the activity by not setting intent filters for it.

  If you do not have intent filters, the default value for this element
  is "false". If you set the element "true", the activity is accessible
  to any app that knows its exact class name, but does not resolve when
  the system tries to match an implicit intent.

  This attribute is not the only way to limit an activity's exposure to
  other applications. You can also use a permission to limit the
  external entities that can invoke the activity (see the permission
  attribute).


Letsencrypt not valid in Firefox or PHP, but valid in Chromium

I just suspect the configuration is maybe wrong somehow, but why Chromium on my PC gives a green light?

If you check your site with SSLLabs you will probably see that it has chain issues, i.e. missing an intermediate certificate. Chrome on Desktop tries to fill in missing certificates by itself and thus works. Firefox will only fill in a missing intermediate if it knows it from some earlier visit to some other site. Mobile browsers will usually not try to work around server side misconfiguration this way and neither to PHP, Python, Java... .


Offering a privacy scenario with PHP mcrypt library

I have some guys, and they want privacy for their cloud (hosting their files).

Sounds like a common goal these days.

  Ok, cryptography is the way to go I believe.

Right.

  So I did some quick research and found that I can crypt their files with PHP and store them crypted in the cloud's server. But this way, to decrypt their files and give them a download of the original file, I'll need to get their crypt key (supposed to be secret and kept only in client side) and use it in PHP mcrypt, to decrypt the file.

If you're typing the word MCRYPT into your PHP code, you're doing it wrong.

  This way, I create a possibility to 'hook' their crypt keys, and decrypt their files even without the permission. Ok, I don't pretend to do that, but I want to "wash my hands" (maybe this expression doesn't work well in English, but try to understand) about what they are hosting there. If anytime, for legal purposes I get obligated to get the key of some user and decrypt the files, I just don't want to have any ways to do that. Is

So basically, you're realizing the limitations of symmetric cryptography: If you have a copy of the key, you can decrypt it.

  Is there any way to do this with the PHP mcrypt library? Maybe doing some hashing function with their crypt key (just supposing) or maybe processing the downloaded file in the client side via javascript (is that even possible?)

No, you cannot do this with mcrypt. You can do it in general, however.

A Better Solution than Mcrypt

Just use libsodium. Specifically, you can use libsodium.js in a web browser, Chrome extension, or Electron desktop application. Encrypt files with crypto_box_seal(), decrypt them on the user's machine with crypto_box_seal_open().

If you need to store anything in the server (i.e. for cross-device encryption), only store the salt (for crypto_pwhash() and crypto_box_seed_keypair()) and require your users to remember a password.

This allows you to design your application with respect to the principle of least privilege and never see their ciphertext. Your users don't need to trust your server operator for anything except availability. Even if you receive a subpoena, you can't decrypt their files.


Why can't the FBI copy the contents of an iPhone they are trying to crack?

When trying to access the content of a hard-drive, you have to use the interface provided by said hard-drive. It usually comes with a firmware.

Currently, it is stated that this firmware will not allow data to be read without providing the correct password and that in case of 10 failed attempts, the data would be deleted.

To circumvent the restriction, you would have to :

rewrite the firmware with a less restrictive one, but the current one will not allow being replaced unless the new one is correctly signed with Apple keys
dismount the whole disks/ssd cells/whatever and put a new component to read from the storage. This requires very good knowledge on how the data has been written in the first place and eventually information that are store by the firmware in it's own memory (such as cell cycling for example). This operation can sometime be really difficult to perform, costly and might result in the destruction of the media.

Clearly the best way for any agency wanting to perform such hack is to ask for a new firmware, as it is easily replaceable and with no risk. Furthermore, the upgrade gets done by Apple themselves and not the agency.

The question about whether such agency are able to perform the latter solution remains open.


Why Yahoo is still using MD5 to hash users passwords?

There are two theories that make sense:

Instead of upgrading their legacy hashes all at once (which is what you should do when migrating hashes), the Paranoids team dropped the ball and decided to do it opportunistically. This left some MD5 hashes in their database while they upgraded to bcrypt. (It's been reported that they had already switched to bcrypt.) This is the most obvious explanation, and somewhat plausible.
Rumor has it they were storing an MD5 hash so they could detect password reuse by fraud accounts.

If #2 holds any truth, a much better solution would have been a second bcrypt hash with a static salt. This would still be slow for attackers, but allow them to perform their password-reuse detection and catch fraudsters.

In the end, however, it could be neither answer. Only Yahoo knows, and unless they tell us, we can only speculate.


How many possibilities can today's computers check (per second) in a SHA512 hash of a 50-byte-long random entry?

The purpose of a salt is not to make computing the hash slower, it's to prevent rainbow tables from being useful. A single iteration of SHA512 is way too fast to be useful against bruteforcing attacks.

On a decent GPU, you can do ~100M hashes/sec (new link) with SHA512. Multiply this for systems with multiple GPUs. With a slow KDF such as bcrypt, you can tweak the iteration count to be more suitable. You want something around ~0.3s/hash for a good security margin.

Keep in mind that 50 bytes is 400 bits, or a keyspace of 2^400. You're almost guaranteed to find a collision in SHA512 if you manage to compute 2^400 hashes. However, the attacker isn't trying to guess the salt. What you should be worried about is an attacker cracking the hashes when they already know the salt.

The solution is use PBKDF2, bcrypt, or scrypt, and store the salt in plaintext in the database.

Update:

It looks like you're trying to implement your own scheme. Please do not do this. There are two widely accepted rules of cryptography:

Cryptography is hard.
Don't roll your own.

I cannot stress strongly enough how dangerous it is to roll your own schemes, especially when dealing with crypto. Not even the legendary Bruce Schneier would dare write his own cryptosystem without serious peer review and months (if not years) of testing and tweaks.

The advice I've given you with regards to hashing is a standard based on peer review and a huge amount of theoretical and practical testing. Attempting to augment it using extra hashing and other black-magic is a bad idea, and will only increase the attack surface of your application and create a potential security flaw. Stick to the standard.


Does the password you use to sign into a VPN determine the strength?

The "strength" of the VPN is twofold. You want two things:

Preventing attackers from spying on your data and/or modifying it silently.
Preventing attackers from framing you, i.e. successfully connecting to the VPN under your name.

If the VPN is any good, then you password impacts only the second type of strength, and the only attack vector for the attackers is an online dictionary attack. "Dictionary attack" means trying potential passwords. "Online" means that the attacker must contact the VPN server for each password he wants to try.

Preventing offline dictionary attacks is very important, because with an offline dictionary attack, the attacker tests passwords on his own machines (e.g. he could obtain a hash of the password), and therefore can speed up the attack by throwing more machines at it. With an online dictionary attack, the attack will be no faster than what the VPN server is willing to accept.

Suppose that the VPN server can "try" 1000 passwords per second; this would be typical of a rather strong PC and a VPN with SSL (SSL connection between client and server, then client shows his password within the tunnel -- there again, the server can botch it by allowing too eagerly SSL session reuse). If the space of potential passwords has size one billion, then, on average, the attacker will have to try 500 millions password before hitting the right one. At 1000 per second, this will take him about 6 days.

This highlights the important points:

The VPN server implementation is important.
The VPN server may decrease the efficiency of attacks by voluntarily lower the number of new connections it will accept per second. Lower from 1000 to 100, and resistance to attacks has increased by a factor of 10.
The password length does not directly matter. What matters is the size of the set of possible passwords.

Whatever is the method by which you generate passwords, you must assume that the attacker knows it (he is evil, after all). The best passwords are generated randomly, with real randomness, i.e. your computer, not your head. If you generate a 10-character password where all characters are digits or letters (lowercase and uppercase), and each character is really chosen at random and independently of the others, then there are 6210 = 839299365868340224 possible passwords; that's the size of the set. And if you use randomness, then the attacker has no other choice than to try them all; at 1000 passwords per second, attack will take him, on average, more than one million years. I daresay that it is sufficient.

So use your best dice, generate ten random characters, and that will be fine. If it is not fine, then the VPN implementation is doing something stupid, and you would be well advised to look for a better VPN. The important points for password generation are:

Use real randomness.
Don't use a "witty" password which is (re)constructed mentally (e.g. taking the first letter of each verse in a Shakespeare's sonnet -- the attacker also knows Shakespeare).
Generate one password and accept it. Remembering a password, any password, is easy if you type it every day. Don't produce many passwords until you find one which "looks good" because it will only decrease your security.
Compute the size of the set of possible passwords; that's the only point where the password length matters. The best point of real randomness is that it makes the possible passwords uniformly probable: this allows you to compute the average attack time, as I did above.
Ideally, publish your password generation technique. Defeating the attacker is good; discouraging him so that he does not even try is better.


A couple of questions about ASP.Net Core default implementation for login security

For the first look, the user ID included in confirmation email look potentially harmful but after a deeper investigation of the code, it looks quite compliant. You have to think of how disclosed user ID can be used in some exploit.

In the confirmation email, the user ID is one of the parameters of URL link to confirm user registration. The email confirmation endpoint uses both values (user ID and code) to validate if the request is legitimate. Looking at the possible responses from this endpoint I do not see any vulnerability like for example possible user enumeration.

According to your second question, I am sure it is also following the best practices of user login feature. The main rule is to not give any clue to the application user that can be used to check if the account exists or not. If you would implement your changed message, when user is registered but not confirmed, possible attacker could use the login endpoint to enumerate different account usernames. If he would get your message in the response, he would know that account exists. When there is only one message to all possible result, attacker is not able to distinguish if account exists or not.


How do I correctly use CORS with OpenID Connect?

When is CORS a risk to security

CORS can override the default rules, so an overly permissive CORS policy can be worse than no policy.

How permissive should CORS be

CORS should be as restrictive as possible while still allowing the use cases you wish to enable. CORS can help prevent CSRF attacks, so care should be taken to not weaken this defence too much.

Where does CORS apply

CORS only applies within the browser, so it does not apply to the options outside of the browser, such as native apps and device login.

Web browser authentication with redirects, or Javascript

CORS applies

A single page application (SPA)

CORS applies

An active client (Flash, Browser Plugin, native phone app)

CORS does not apply - not inside of a browser

Device flow (Activating AppleTV)

CORS does not apply - not inside of a browser


How do I prepare for Certificate Authority end of business?

Certificates are transient in nature: they expire, and must be renewed. Even worse, the validity of a certificate is the property of the current time, since certificates may be revoked at any time. Therefore, if you want to store signed documents, and be able to validate them at a later date, then you need time stamps. See this answer for some details.

While time stamps protect your signed documents against a cessation of activity from the CA, an abrupt closure would still be a problem since, by ceasing to issue CRL on a regular basis, the CA effectively revokes all existing certificates (at least that's the effect from the outside). Normally, contracts with CA include strict clauses on the continuity of operations; up to an including financial provisions and/or to guarantee that even in case of total business failure, CRL will still be issued for some years.

When you renew your certificate, you are actually acquiring a new one. Nothing forces you to get that second certificate from the same source as the other one. You may think of these certificates as "the old one" and "the new one", but from an X.509 point of view they are just two certificates, that may relate to distinct issuing CA. You will have to renew certificates on a regular basis anyway, since they have expiration dates. An out-of-business CA may "just" force you to renew earlier than expected.

Alternatively, you may want to operate your own CA, but it is going to be very expensive if you want to do it properly (a serious CA is 5% technology, 95% people and procedure).


Is using htmlentities or htmlspecialchars functions enough to block XSS attack

htmlentities is the better function to use as it encodes all possible characters.

The only way I can see XSS being achieved in your example is with Internet Explorer if the charset is set to UTF-7.

If your charset is UTF-7 then

+ADw-script+AD4-alert(document.location)+ADw-/script+AD4-

becomes

<script>alert(document.location)</script>

when interpreted by the browser. Additionally, htmlentities does not cause any encoding of the characters.

Bear in mind that only old versions of Internet Explorer will auto detect UTF-7 - it would need to be explicitly set in modern versions (either by the website author or by the attacker using some other vector) - see this answer.


How did Google know I looked something up?

Loading that page loads

https://www.googleadservices.com/pagead/conversion.js
https://www.googletagmanager.com/gtm.js?id=GTM-WPPRGM
https://stats.g.doubleclick.net/dc.js

The reason Google can track you is that the website shares details of your visit with them - in this case via loading Google JavaScript code for their ads service.

*To expand on this -

The Google ad code will use a cookie to track you. But even if it didn't there are browser fingerprinting mechanisms which in most cases can correctly identify a user's machine even after a full browser cache / history clear.

When you visit a site with ads a request is made to the ad providers server. This sends the ID associated with you to say "an ad on [x website] for [user y] is available. The ad providers nowadays often then real-time auction off the slot in 1/100th of a second - where potential advertisers computers can bid for the advert space.

The site you visited is djoser. Since djoser knows you looked at products on their site yesterday they know there is a reasonable chance you are considering buying something from them. So when you visit another site somewhere else, the ad slot on that other site is more valuable to djoser, and they bid higher than anyone else - hence why you keep seeing them.


What lightweight sandboxing options do I have on linux?

Classic VM: There are two kernels, the hypervisor uses CPU feature to emulate a hardware, and the guest kernel is generally unaware that it is running on a virtualized system. This is generally considered to give the best isolation, however giving restricted access to the guest system can be tricky as many security features needed to be enforced by the guest system.
Paravirtualization: There are two kernels, the guest kernel is aware that it is being virtualized and it uses a paravirtualization driver that is specifically designed to talk to the host kernel/hypervisor for hardware access instead of trying to access an actual hardware. This is middle of the road in terms of isolation and flexibility.
Container: There's only one kernel, the kernel creates a namespace for each container so that the containers can't see each other. This gives you the least isolation, as any security bugs in the kernel can break out to the host system, but also most flexible if you need to define complicated access restriction. For example, with container you can define an SELinux policy that will be applied to the guest system but enforced by the host system.

If you want to run a known malware, I suggest using a full blown virtual machine. As currently implemented, container technology like rkt and docker isn't intended to be unbreakable by privileged processes running inside the container. However, note also that there are a certain class of malware called blue pill malware that are designed to break out of classic virtualization by exploiting flaws in the hypervisor. While these are quite rare, it makes it not advisable to run malware samples if you have zero clue what it is supposed to do.


If the public key can't be used for decrypting something encrypted by the private key, then how do digital signatures work?

The whole concept of trying to explain signatures with the terminology of encryption is flawed. It simply does not work. So let's unravel the whole thing, and this will require some formalism.

Formally, a cryptographic signature system consists in three algorithms:

KeyGen: takes as input a "security parameter" (say, the length of the key we want to obtain), and produces a new public/private key pair (Kp, Ks).
Sign: takes as input a message m and a private key Ks; output is a signature s.
Verify: takes as input a message m, a signature s and a public key Kp; output is a boolean (true on success, false if the signature is not valid).

The system is said to be sound if the algorithms operate as advertised (Sign produces signatures that Verify accepts, using key pairs produced by KeyGen). The system is said to be cryptographically secure if it is computationally infeasible to make forgeries: given a public key Kp, and without knowing Ks_, it should not be feasible (within the limits of existing technology) to produce a (m, s) pair such that Verify(m, s, Kp) = true. The definition implies, in particular, that the private key should not be computable from the public key alone, because otherwise forgeries would be easy.

None of the above says anything about how the algorithms work. Various systems have been invented, described and standardized.

RSA is a very well-known asymmetric algorithm, but that's wrong, because RSA is not one algorithm. RSA is the name for an internal operation called a trapdoor permutation, from which an asymmetric encryption system and a signature system have been derived. The RSA operation is, roughly, the following:

Let n be a big integer such that n = pq, where p and q are two big, distinct primes. Knowledge of p and q is the "private key". Let e be some (usually small) integer, called the "public exponent"; e must be such that it is relatively prime to both p-1 and q-1. Traditional values for e are 3 and 65537.
Given an integer x modulo n (an integer in the 0 to n-1 range), the RSA forward operation is computing xe mod n (x is raised to exponent e modulo n). This is easy enough to do. It so happens that this operation is a permutation of integers modulo n (each y modulo n is equal to xe mod m for exactly one x). The "magic" part is that, for some reason, nobody found an efficient way to compute the reverse operation (getting x from xe mod n) without knowing p and q. And that's not for lack of trying; integer factorization has been studied by the finest minds for more than 2500 years. When you know p and q, the RSA reverse operation becomes easy. The knowledge of p and q is thus called the trapdoor.

Now that we have this trapdoor permutation, we can design a signature algorithm which works the following way:

KeyGen: given a target length k, produce two random primes p and q of length about k/2 bits, such that p-1 and q-1 are both relatively prime to an a priori chosen e (e.g. e = 3), and n = pq has length k bits. The public key is (n, e), the private key is (p, q, e).
Sign: take message m, hash it with some hash function (e.g. SHA-256), and "turn" the hash output (a sequence of 256 bits in the case of SHA-256) into an integer y modulo n. That transform is what the padding is about, because the standard method (as described in PKCS#1) is writing the hash output with some extra bytes, and then interpreting the result as an integer (in big-endian convention in the case of PKCS#1). Once the hashed message has been converted through the padding into an integer y, the private key owner applies the trapdoor (the reverse RSA operation) to compute the x such that xe = y mod n (such a x exists and is unique because the RSA operation is a permutation). The signature s is the encoding into bytes of that integer x.
Verify: given a signature s, decode it back into an integer x modulo n, then compute y = xe modulo n. If this value y is equal to what would be the padding of h(m) (hash of message m), then the signature is accepted (returned value is true).

RSA encryption is another, distinct system, that also builds on the RSA trapdoor permutation. Encryption is done by raising an integer x to the exponent e modulo n; decryption is done by reversing that operation thanks to the knowledge of the private key (the p and q factors). Since such a system processes only big integers, and we want to encrypt and decrypt bytes, then there must also be some sort of conversion at some point, so a padding procedure is involved. Crucially, the security requirements for the encryption padding are quite distinct from those for the signature padding. For instance, the encryption padding MUST include a substantial amount of randomness, while the signature padding MUST include a substantial amount of determinism. In practice, the two padding systems are quite different.

When people looked at RSA signatures and RSA encryption, they found it fit to describe signatures as a kind of encryption. If you look at it, the RSA forward operation (raising to the exponent e) is done for RSA encryption, and also for RSA signature verification. Similarly, the reverse operation is done for RSA decryption, and for RSA signature generation. Furthermore, as a stroke of genius if genius was about confusing other people, some noticed that the RSA reverse operation can also be mathematically expressed as "raising an integer to some power modulo n", just like the forward operation (but with a different exponent). Thus they began to call that reverse operation "encryption". At that point, RSA encryption, RSA decryption, RSA signature generation and RSA signature verification are all called "encryption". For some weird psychological reason (I blame the deleterious effects of post-Disco pop music), many people still find it pedagogically sound to try to explain four different operations by first giving them the same name.

We described RSA; let's have a look at another, completely different algorithm called DSA. DSA does not use a trapdoor permutation. In DSA, we do computations modulo a big prime (traditionally called p) and modulo another, smaller prime (called q) which is such that p-1 is a multiple of q. p and q are known to everybody.

There is an operation-that-goes-one-way in DSA. Given an integer g modulo p (strictly speaking, in a specific subset of p called the subgroup of order q) and an integer x modulo q, everybody can compute gx mod p; however, recovering x from gx mod p is computationally infeasible.

While this somehow looks like RSA, there are crucial differences:

Here, the operation is raising g to exponent x, where the actual input is x (the exponent), because g is a fixed, conventional value.
This is not a permutation, because x is an integer modulo q and gx mod p is an integer modulo p, a quite different set.
This is certainly not a trapdoor: there is no "secret knowledge" that allows recovering x, except if you already know that exact value x.

However, a signature algorithm can be built on that operation. It looks like this:

KeyGen: the p, q and g integers are already fixed, and potentially shared by everybody. To generate a new private key, produce a random integer x between 1 and q-1. The public key is y = gx mod p.
Sign:

Given a message m, hash it, then convert the hash value into an integer h modulo q.
Generate a new, fresh, discard-after-use random integer k between 1 and q-1.
Compute r = gk mod p mod q (the exponentiation is done modulo p, then the result is furthermore reduced modulo q).
Compute s = (h + xr) / k mod q. The signature is (r, s).

Verify:

Hash message m to recompute h.
Compute w = 1 / s mod q.
Compute u1 = hw mod q.
Compute u2 = rw mod q.
Compute v = gu1 yu2 mod p mod q.
If v = r, the signature is valid; otherwise, it is not.

Now good luck with trying to describe that as some sort of "encryption". If you find that it is unclear what is being encrypted here, it is because nothing is encrypted here. This is not encryption.

However, there is an hand-waving conceptual description of signatures that works with both RSA, DSA, and many other signature algorithms. You can view signatures as a specific kind of authentication.

In authentication, one person (the prover) demonstrates his identity to another (the verifier). The prover does this by performing some action that only that person can do, but in such a way that the verifier can be convinced that he witnessed the genuine thing. For instance, a very basic authentication system is called "show-the-password": the prover and the verifier both know a shared secret (the "password"); the prover demonstrates his identity to the verifier by uttering the password.

For signatures, we want something a bit more complex:

The signature is asynchronous. The signer acts once; verification is done afterwards, possibly elsewhere, and without any further active help from the signer.
The verifier should not need to know any secret. The signature should be convincing for everybody.
By signing, the signer shall not reveal any secret. His private key should not be consumed (yes, I know there are signature schemes that work with consumption; let's not go there).
The signature should be specific to a given message m.

One rather generic structure for authentication schemes is based on challenges: the verifier sends to the prover a challenge, that the prover can answer to only thanks to his knowledge of his secret.

If you look at RSA, then you can see that it is a challenge-based authentication mechanism. The challenge is the hashed-and-padded message. The signer demonstrates his mastery of the private key by applying the RSA reverse operation on that challenge, something that only he can do; but everybody can apply the RSA forward operation to see that the challenge was indeed well met.

If you look at DSA, then you can again see a challenge-based authentication mechanism. The signer first commits to a secret value k by publishing r; then the challenge is (again) the message h combined with the commitment r; the signer can answer to that challenge only by using his private key x. In DSA, the signer has a permanent private key x, produces a one-shot private value k, and demonstrates his knowledge of x/k mod q. (This does not leak information on x because k is used only once.)

Summary: signature algorithms are not encryption algorithms, and explanations of signatures based on encryption can only be, at best, utterly confusing. A much better explanation is by showing that a signature algorithm is, in fact, a specific kind of authentication mechanism, by which the signer demonstrates his knowledge of the private key in response to a synthetic challenge that involves the signed message.

This authentication is convincing for bystanders as long as the said challenge is sufficiently well specified that it is provably not cooked in the advantage of the signer. In RSA, it is the result of a deterministic hashing and padding (and the padding takes care to avoid the values where the RSA reverse operation becomes easy). In DSA, the challenge is computed from a prior commitment of the signer.

Indeed, any zero-knowledge authentication system can be turned into a signature mechanism by making it non-interactive: since a ZK system works by commitments, challenges and responses to these challenges, you can make the signer compute all his commitments, hash them all along with the message to sign, and use the hash value as the challenges. This does not mean that a ZK proof lurks within all signature algorithms; however, if you find that DSA kinda looks like that, well, there are good reasons for that.


Why use HTTPS Everywhere when we have HSTS supported browsers?

HSTS uses a Trust on First Use model. If your first connection to the site was already compromised, you may not receive an HSTS error on subsequent requests.

The HTTPS Everywhere plugs this hole, by letting your browser know that the site is an HTTPS only site from the first connection.

Also, some websites don't advertise an HSTS header even when they support HTTPS. Or they may have their HTTPS be in a different domain/path (e.g. http://www.example.com but https://secure.example.com), HTTPS Everywhere attempts to help with these situations by rewriting the site's URLs.


Is password information dumped from the MySQL user table sensitive?

Yes, it's sensitive information. It's a password hash leak.

Attackers will supply this information to a bruteforce application (there are some tailored just for MySQL) and retrieve the password.

Not only this, but the % on the host field means that if your MySQL port (3306 by default) is not firewalled, the attacker can access it as admin from anywhere.

Consider locking the admin account just for localhost, and never disclose a password hash, no matter how confident you are on the difficulty of breaking such hash.


I need ideas for blocking a single malevolent user

@logicalscope raises some good suggestions, but overall you still have to deal with one cold hard fact:

  Technically speaking, even this Nigerian prince guy is a perfectly valid user.

The only problem with him, is that he does not own the credit cards which he is providing - notwithstanding the fact that he provided all the validation necessary.
This is actually a failing of the credit card system itself - treating what you know (the CC numbers) as something you have (the credit card itself).
And, since these numbers are nearly in public domain (i.e. you give them to many sites, you hand the physical card to the checkout girl in your supermarket and the attendant at the gas station, etc), knowledge of them should not be treated as proof of card ownership.

Bottom line, formally you should be able to rely on the proof given, unfortunately there is the little issue of chargebacks. So, basically, the credit card companies are doing what they do best - screwing you from both directions :).

Ranting aside, what can you realistically do, to avoid charging a card that is not owned by someone who provided the CHD?
Well, not much (and I am thrilled noone suggested CAPTCHA....) However, your idea of minimal charges as a form of proof of ownership is a very good one.

It is very similar to Paypal's method, and I would in fact suggest modifying your scheme slightly in their direction. When signing up (IIRC), a single small charge is made. The amount is not the secret, as there are only so many sums that can be made in the sub-dollar range... instead, they ask you for the transaction number, that shows up on your credit card report. The only way to get access to that, is either to receive the card-owner's mail, or to have access to the CC provider's consumer portal. For the record, they also refund that dollar after you signed up.

Perhaps you want to implement this only for potentially risky accounts, as @logicalscope suggested - such as by IP geolocation.

One other possibility I think you should look into, is outsourcing card validation. Either by accepting only Paypal accounts, or using a 3rd party validation system. This transfers the responsibility to someone else, by having someone else accept the payment directly for you (ala VBV/3Dsecure).


Are SSL Certificates (Private and Public key) generated by OpenSSL and makecert compatible?

Both makecert and OpenSSL follow X.509, so they are compatible -- in theory. X.509 is extensible is various arbitrary ways, and has been extended in various arbitrary and exotic ways, so anything can happen.

Practically, OpenSSL powers a lot of existing HTTPS web sites (according to these statistics, Apache powers more than 50% of all Web sites, and when Apache does HTTPS, it does so with OpenSSL(*)) so chances are that Microsoft tried not to break compatibility in that matter. In my experience, .NET and OpenSSL talke to each other quite politely.

(*) Well, Apache can also use GnuTLS, but it seems to be rather uncommon.


is it safe to AES encrypt the RSA private key and storing it in the database

It really depends on your threat model. However, properly-implemented AES encryption will ensure confidentiality for any arbitrary data, including an RSA private key. There is nothing special about RSA which would make it unsafe to encrypt using a symmetric algorithm.


Unauthorized domain comes up as my website

I don't think they are actually redirecting to your site. If it was a true redirect, then the phone number couldn't be different. My guess is your website was scraped and copied to another site. They registered a new domain and used the content of your site. Then they created some spam SEO links to trick Google into moving them up higher in the rankings to get traffic to their site. They purchased a new phone number that is very similar to yours and the plan is to wait for the phone to ring. When it does, they take an order over the phone and now they have stolen someone's credit card number. This could go one for days or even weeks before Google figures it out and shuts them down.

It may be too late now, but I'd call the phone number and see who answers.


No. There's no such thing as a message sent from https://example.com to anywhere; a message is sent from a device, not a URL. A user visiting your site sends messages from their computer to your server, and your server sends messages to their computer; the https in the URL means that they initiated that connection with the HTTPS protocol, and your server (when it receives HTTPS messages) is configured to respond with replies using the HTTPS protocol. If you initiate a connection to http://anotherexample.com from your server, you are initiating a connection from your server to the host of anotherexample.com using the HTTP protocol, which is not encrypted -- it's irrelevant that a user had previously connected to your server with HTTPS, because that's a different connection.


Ecuador's government confirms that they cut Julian Assange's Internet connection, after another batch of email exchanges (involves Ms Hillary Clinton) was leaked by Wikileaks, at its embassy in London.
As per news, the DDoS attack was generated to take revenge for this.

Wikileaks requested the attackers to stop the DDoS attack immediately.

Type of attack
Latest reports indicate that the DDoS attack on Dyn infrastructure (particularly DNS servers) was generated using infected IoT devices (like CCTVs, WebCam and others).
The source code of one such malware named Mirai was released on the Internet recently. It is speculated that this malware was used for generating the attack.


user/pass auth vs hmac signed for REST API

Here are a few things to think about:

For mobile apps: do you stored the user's password on the device? At that point you add risk in case the device is stolen. If you use some form of token based authentication, you store the token and not the password - given how users reuse passwords, any chance to reduce the chance of exposure is good.
I wouldn't call salted password hashes useless - they can still be broken as long as the salt is taken as well. Depending on how the hashing is done, even salted, an attacker is likely to have a high success rate.
Unless the calling application has 'pinned' the certificate, don't assume safety from MiTM attacks. While it may require unusual circumstances (hacked CA, CA issuing signing certs, etc), it can (and has) happened.

To figure out the right answer though - depends on the specific threats a service is facing, and which risks are considered most important.


Why is Windows auditing svchost by default?

It seams that other files and folders are also audited by default (explorer.exe , \Windows\Boot, \Windows\SystemResources...).
It becomes a problem when Remote Desktop is used by many users, the log grows a lot.


Who other than my ISP can perform man-in-the-middle attacks?

Government agencies can do so (if they really want to) by using a subpoena on any of the intermediary providers or on any of the end nodes. A "random" IP "somewhere on the internet" cannot just listen in on your traffic. If it can not re-route traffic past himself then there is no chance of eaves dropping onto the connection.

Anyone who  has access to your transfer medium can theoretically snoop on your connection. This can be someone who's also connected to the same wireless AP as you or any of the ISPs between you and your end point.


Is the core idea behind CSRF protection that the hacker doesn't know the token value?

Your understanding is correct.

Background

The simplest way to think of a CSRF attack is that your browser has two tabs open - Tab A:  www.mybank.com and Tab B: www.attacker.com.

(As @Alex points out in comments, multiple tabs are not necessary; the important part is that your browser has auth cookies for mybank.com in memory. CSRF can equally happen if you were on mybank.com earlier and then without logging out, browse to attacker.com)

Cookies

Historically, it was common to store your auth / session token in a cookie. This is convenient for pure HTML pages (ie no javascript) because when you send a request to www.mybank.com, the browser will automatically attach any relevant auth cookies -- no action required on the part of your HTML page in order to maintain the session. CSRF is an attack on cookie-based auth tokens: if Tab B (www.attacker.com) sends a request to www.mybank.com, the browser will automatically attach the authentication cookie, ie Tab B can send requests as if they were logged in to Tab A.

Solutions

You need to put your auth / session token somewhere that's not a cookie. Remembering that Tab B can't see any of the content in Tab A, there are any number of places you could put the auth / session token:

somewhere on the HTML page (maybe in a hidden HTML element),
or in a non-cookie HTTP Response Header,
or if this is an API then you could put it in a token: ___ field of the JSON body, etc.

It really doesn't matter where, so long as it's not in a cookie.

For completeness, I'll add that your anti-CSRF token needs to be long and random enough to prevent the attacker from guessing it. For example, if you use the same anti-CSRF token for all users, or you derive it from the user name, then it doesn't matter that Tab B can't read the content of Tab A because they can guess the token and include it in their blind CSRF request.

References

OWASP Cross-Site Request Forgery (CSRF)
OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet


Which cipher suites with AES cipher provide forward secrecy?

Cipher suites which provide perfect forward secrecy are those which use a Diffie-Hellman key exchanged, signed by the server -- but the server key may be of type RSA. Consider the TLS standard: there are two cipher suites which use AES with a 256-bit key, SHA-1 for integrity check, and a RSA server key:

TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA

Only the latter provides perfect forward secrecy. In the former, the key exchange is done by encrypting a random value with the RSA server keys, something which can be unraveled later on by an attacker who could steal a copy of the server private key.

Information provided by Opera does not seem to be sufficient to distinguish between those two cipher suites.


How safe is it to use SMB file share on a machine running up-to-date Windows 10 LTSC through the Internet?

how secure is my setup?

0-day exploits notwithstanding you're secure as long as your users/passwords combinations are secure as well and you install Windows updates immediately after they are released and reboot afterwards.

Provided that my computer has some sensitive data in it.

People generally oppose having CIFS ports wide open to the Internet, however I haven't heard any strong arguments against it. In the past, people had often had trouble keeping their Windows NT/2000 installation secure because the Internet was in its infancy, which meant that many servers had glaring vulnerabilities. Nowadays it has long become a non-issue unless you meddle with Windows updates.

Is there a better way to manage files on a remote computer that I'm missing?

SSH/SCP/SFTP with private keys could be a tad more secure.

Is data I'm transferring encrypted? PS: heard that starting with SMB 3.0 it is, but how do I check what version I have on my current Windows installation?

Windows 10 uses 128 bit AES SMB encryption by default  if you're using SMB 3.1.1.
SMB 2.0 or SMB 1.0 connections are not encrypted.

Does the latest version of Windows 10 LTSC contain any unpatched vulnerabilities that would allow privilege escalation?

Not a single person in the world could answer this question but if we're talking about publicly available data, then the answer will be "no".


Do not use DSA keys. They are fixed 1024 bits and not secure enough today. Generate a new RSA key and your steps should work:

ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

If the RSA does not work either, most probably there will be a problem with permissions (which is in the debug log of the server). Make sure that your home directory, the ~/.ssh/ and authorized_keys files are owned by you and not writable by any other user/group.


Is CSRF possible in a Client Application?

For CSRF to work in a browser, the user needs to be authenticated in the browser. This is generally not the case with non-browser applications where users authenticate in the application, not the browser.

What you would need for a successful CSRF attack in such an application would be to somehow force a user to perform actions using the application.

For example, if the application processes user-supplied links to perform state-changing actions, then CSRF may be possible (see this example for an Android application processing deep links).


RHEL7 SSGv0.1 2.2.3 Unauthorized SUID/GUID executables

Run rpm -V "$(rpm -qf "/usr/bin/pkexec")", for each file to check. If you see an entry like .M.......    /usr/bin/pkexec, then the file's mode has been modified. If not, then it's still the same as when it was installed (and for pkexec, it is indeed supposed to have it). Repeat for the rest of them.

Note that this assumes that your package management infrastructure hasn't been compromised, but if it has, then you can't trust anything anyway.


Code Signing: Change certificate attributes during renewal?

Alternatively you can timestamp your code so that it remains valid even after the code signing certificate expires. There are more details about this in StackOverflow here and here.


This says it better than I can:

  the purpose of a GUID is to be globally unique, not to be unguessable.

and

  GUIDs are designed for uniqueness, not for security.

So if you're concerned that an attacker could validate an email address that is not theirs, then do not use a GUID.

Since it is a simple thing to solve, instead generate a 128 bit token using a CSPRNG.

Also use HTTPS to ensure the parameter is encrypted during transit. You should check whether the session matches the original, or ask them to login again after following the link just in case any security products decide to follow the link for scanning before it gets to the user (otherwise they could confirm email addresses for users that never registered).

You should also redirect via HTTP and store the value within their session while you wait for them to confirm, to guard against referer leakage - otherwise any resources on your page from another domain would get your token sent to them within the referer HTTP request header.


Can I instruct a Telco to prevent 2G connections from our phones?

Asking the telco to do this would not solve your problem. The biggest issue with 2G is that the base stations are relatively cheap (approx. £600; this is from someone who gave a talk at Over The Air) and, loaded with OpenBTS, can allow an attacker to set up a nefarious 2G base station wherever they want. Unless you can lock the phone down to only use 3G, or to only use certain base stations, you have a problem.

Here is a rather good video from Chaos Computer Club Congress which explains a lot of the details of how mobile phone networks work (I've been to other talks where they've demonstrated 2G highjacking with an OpenBTS base station). It can get very technical (and there are a grotesque number of acronyms) but may help with anything mobile.

http://www.youtube.com/watch?v=759Ftfe2TUM


Just how much of a risk am I putting on my network by allowing UPnP

UPnP's authentication model is, for the most part, "did I get a UPnP packet? yes? cool, I'll do whatever it says". The reason that this is generally considered acceptable (at least in home environments) is that the UPnP server only listens on the internal network, which is considered trusted.

Problems with UPnP arise if your threat model includes an attacker who has access to your network. Many routing devices support a wide range of configuration via UPnP, including DNS settings and routing tables, which may enable man-in-the-middle attacks against your traffic if maliciously configured.

A common place you'll see dangerous UPnP configurations is small hotels and businesses offering free WiFi. The routers are often consumer devices left in their default state, with UPnP enabled, so anyone can configure them because, by business requirement, untrusted people have access to the network.

For the large part it makes sense to just turn UPnP off if you're not expecting to have lots of unknown programs needing dynamic port forwarding. You should also verify that UPnP is actually switched off when you disable it on a settings page; there are numerous cases of consumer routers where the UPnP disable functionality either does not work at all, or only alters the boot config to not launch UPnP on next boot without stopping the existing UPnP daemon.

If you're concerned about UPnP but do require it for administration, find a way to move the UPnP listener onto an administrative VLAN rather than the primary VLAN.


How did my professor sniff my Gmail password?

I'm not entirely sure, but I believe that any decent corporate firewall has the tools to do some decent (deep) SSL inspection.

This is available to firewalls in order to do application control, antivirus scanning, data leakage prevention, etc.

Basically client SSL connections can get proxied through the firewall and unless this "freshly installed computer" would not trust the firewall's certificates itself, it appears to be technically feasible to log sensitive data on the firewall.

How HSTS comes into play with these proxy-based is not entirely clear to me, but I guess that unless OP was using a recent legit version of Google Chrome to navigate to gmail.com, it would be difficult to entirely exclude this "SSL inspection" possibility. Even if he did, I am not sure SSL inspection is undoable.

In any case, whether or not its done via a firewall, this would probably require a certificate to be preinstalled in the PC's cert store.


Methods for storing plaintext passwords on a client

The quick and easy (but wrong) solution is have a master password to encrypt the logins and passwords. You'll need to type this password each time you run the script. If you don't want to have to type it each time, you can see this question for other options.

The correct way to do this is go to the admin of your internal site and ask them for web scraping credentials that give you all the proper access rights to scrape what you need. You should never really have access to logins and passwords of others. It's dangerous for the company and a liability for yourself if something bad happens. Unfortunately, this may not be an option as it requires cooperation from someone else.


Malwarebytes found bitcoin miners after I installed a new drive. Is my system screwed?

From the report, it seems your antivirus stopped the programs before it could have done anything. I would just flash the hard drive and use it or return it and get a new one. As for why it was there I'm guessing someone purchased the hard drive and put the files there then returned it hoping someone would install it by mistake.

PS: As a safety measure I would scan the whole PC with the antivirus.


It sounds like you're trying to invent some sort of "DropBox" clone.

  Security of a single encryption algorithm is well studied, while stacking multiple ones is unknown (e.g. NaCl() vs. AES(NaCl())

I think this does not apply. I can not make a hard mathematical argument here, but for independent encryptions, with completely unrelated keys, the strength of the compound encryption can NOT go down at all. And will be at LEAST as strong as the weaker of the two encryptions. That's all. It's just preventing the simple addition of two key lengths. Worst case you end up with the lower of the two key lengths in the stack. That's for independent keys only. Which we can assume for a combination of at-rest encryption and TLS-session-key encryption. (Correct me if I'm wrong, Sec:SE.)

  Simplicity (at rest == in transit)

I think this is will be greatly offset by the complexity of your own authentication/signature scheme.

  Increased server load (zero-copy sendfile(2) vs. copying to RAM for TLS encrypt).

I think the impact on latency and throughput will be negligible. Maybe not even measurable. I'd insist on a benchmark. (-> See https://istlsfastyet.com/ )

And again: No idea how much of an impact the auth scheme will have.

  Server validates token (to prevent reuse) then streams encrypted archive files to/from disk.

This means that the server is NOT dumb storage anymore.

Instead what about setting things up like a mirror for a Linux distribution? Signed archives on dumb (S)FTP? Since you do client side verification anyway.


How to generate dictionary for a dictionary attack?

So you could use python to generate all possible combinations using itertools.permutation

import itertools
res = itertools.permutations('abc',3) # 3 is the length of your result.
for i in res:
   print ''.join(i)

where 'abc' is a string of possible characters. Note that a and A are not the same!

This will output:

abc
acb
bac
bca
cab
cba

Edit (thanks to @buherator):

If you want repeated letters (e.g. aaa, etc), you need to use itertools.product instead. For instance,

import itertools
res = itertools.product('abc', repeat=3) # 3 is the length of your result.
for i in res:
    print ''.join(i)

This will output:

aaa
aab
aac
aba
abb
abc
aca
acb
acc
baa
bab
bac
bba
bbb
bbc
bca
bcb
bcc
caa
cab
cac
cba
cbb
cbc
cca
ccb
ccc


Is it good to not have keyboard-based sequences in our password generator?

I would say yes. @Philipp does make some good points, but how many passwords would actually fall out if you remove keyword based sequences? Probably not enough to make any real difference (depending on how you actually filter, of course).

The probability that such a password is generated is (probably) incredibly low (so another question is if it's actually worth the work to implement such a filter), but if it actually does happen, it would be quite bad, because then that generated password is easy to guess, which is exactly what you want to avoid with generated passwords.

When you do filter, the length of the keyboard based sequence that you filter should be in some reasonable proportion to the password length. So if you generate passwords of lenght 15, filtering out asd is probably not a good idea (because asd in a long password doesn't lead to easily guessable passwords, but you would actually exclude a rather wide range of passwords). I would probably exclude the password if it contains a sequence of length of about  password.length - 4 (4 additional characters to a sequence seem enough to avoid simple bruteforce).

If you do filter the generated passwords, I would also filter against a list of common passwords (you really don't want your password generator to generate 123456 or password1).


Does the SSL encryption strength or validation level of a website really matter?

The important part in the page you point to is the "guarantee": how much money NetworkSolutions puts at stake. The options all boil down, more or less directly, to that.

Cryptographically speaking, the "encryption strength" will depend on the type and size of your public key (the one you will put in the certificate) and the cipher suites you configure on your SSL server; this is mostly orthogonal to the certificate "category". NetworkSolutions might enforce some requirements on the public key (e.g. requiring a 2048-bit RSA key for the more expensive certificate types); but SSL server configuration is completely out of their reach.


Just imagine if these different constants where not there: then the MS would consists of three equal parts and would therefore be much weaker. The value of the constants actually does not matter, but they should be different and be the same in both client and server.

That a concatenation of the results of same basic algorithm but with different constants is done in the first place, is necessary since a single MD5 does not provide sufficient length for the master secret. See also How key materials are generated in SSL V3 from master secret and also have a look at the definition of P_hash in TLS 1.2 which uses a similar construct.


Is a SPA vulnerable to the BREACH https security exploit?

From your link:

  To be vulnerable, a web application must:

  Be served from a server that uses HTTP-level compression
  Reflect    user-input in HTTP response bodies
  Reflect a secret (such as a CSRF    token) in HTTP response bodies

However, if your resources are static and are the only items compressed then:

Be served from a server that uses HTTP-level compression
Reflect
user-input in HTTP response bodies
Reflect a secret (such as a CSRF
token) in HTTP response bodies

For your non-compressed dynamic items:

Be served from a server that uses HTTP-level compression
Reflect
user-input in HTTP response bodies
Reflect a secret (such as a CSRF
token) in HTTP response bodies

Key:

Applicable to your situation
Not applicable

As no one request satisfies all three requirements, you are not vulnerable to BREACH.


Can F5's Big-IP ASM protect against CSRF for AJAX calls?

It will depend on what F5 software version you have. In the past, ASM only operated by injecting the token in fields on static HTML POST forms, and could not address other kinds of request or client-side-scripting-driven interactions.

It looks like more recently the CSRF feature can now inject client-side script to:

Apply the CSRF token to GET forms and plain links. This is a really bad idea—you don't want to leak your CSRF tokens in URLs.
Frob the XMLHttpRequest prototype to inject a fixed-value custom header X-TS-AJAX-Request: true to bypass CSRF protection. This is workable but custom headers are the poor man's solution, compared to proper tokens; they have been vulnerable to edge-case attacks like that from Flash in the past.

These features, like much of what ASM does, are useful as a last-ditch/temporary workaround for when you have to deploy applications you know are insecure but you don't have the ability or permission to fix them properly. But if you can, it is much more reliable to address the problem in the application itself.


With anonymous cookies

If you are happy to generate secure tokens which are set as anonymous users' cookies, but not to store them server side then you could simply double submit cookies.

e.g. Legitimate user:

Anon user navigates to the login page, receives cookie which is sent to the browser.
Anon user logs in and the browser sends the cookie as a header and as a hidden form value.
User now logged in.

This cannot be abused by the attacker as the following will now happen:

The attacker creates a host account on the trusted domain
The attacker forges a login request in the victim's browser with this host account's credentials However, the attacker does not have access to the victim's cookie value and cannot forge it as the CSRF token in the request body. The attack fails.

Even if your site is only accessible over HTTPS and you correctly set the Secure Flag, care must be taken with this approach as an attacker could potentially MiTM any connection from the victim to any HTTP website (if the attacker is suitably placed of course), redirect them to your domain over HTTP, which is also MiTM'd and then set the required cookie value. This would be a Session Fixation attack. To guard against this you could output the cookie value to the header and the hidden form field every time this (login) page is loaded (over HTTPS) rather than reuse any already set cookie value.  This is because although a browser can set the Secure Flag, it will still send cookies without the Secure Flag over a HTTPS connection, and the server will not be able to tell whether the Secure Flag was set. (Cookie attributes such as the Secure Flag are only visible when the cookie is set, not when it is read. The only thing the server gets to see is the cookie name and value.) Implementing HSTS would be a good option for protection in supported browsers.

It is advisable to set X-Frame-Options to prevent a UI redress click jacking attack (otherwise the attacker could possibly use site functionality to pre fill their username and password awaiting the user to click and submit them along with the CSRF value).

Without anonymous cookies

If you do not want to set cookies for anonymous users (which then may suspect that they are being tracked server side) then the following approach may be used instead: A multi-stage login form.

The first stage is the usual username / password combination.

After the form is submitted, it redirects to another form. This form is protected by a special intermediary authentication token cookie and a CSRF token. The authentication here will only allow the second stage authentication to be submitted, but will not allow any other actions on the account (except possibly a full logout). This will enable the CSRF token to be associated and used by this user account only on this intermediary  session.

Now it is only when this form is submitted, including the token cookie and CSRF hidden form value that the user is fully authenticated with the domain. Any attacker attempting a CSRF attack will not be able to retrieve the CSRF token and their full login attempt will fail.

The only drawback is that the user will have to manually click to complete login, which may be a clunky user experience. It is advisable to set X-Frame-Options to prevent this being used in combination with a UI redress click jacking attack. Any auto submission with JavaScript would be beneficial to the attacker and would cause their attack to possibly succeed, so at the moment I can only see a manual click by the user working.

It would now play out like this:

The attacker creates a host account on the trusted domain
The attacker forges a login request in the victim's browser with this host account's credentials but they cannot proceed past stage two to become fully authenticated
The attacker tricks the victim into using the trusted site - but as they are not fully authenticated, the site will act as though the user is unauthenticated


Guidelines for time for encryption key regeneration

No, there aren't any standard formulas. The reason for that is that e.g. an AES-128 key may be used for very large amounts of data. Modes of encryption, protocol requirements and requirements on the data itself however do pose limits and those limits are usually much lower than the one for the symmetric cipher.

Say that you could use an AES key to encrypt 2^48 blocks in CBC mode. In that case you could encrypt 2^52 bytes or 4.503.599.627.370.496 bytes or about 4.5 peta byte if I'm not mistaken. And that's for CBC mode, the block cipher itself should have higher limits.

So the question is more how much separation you require between the protected blobs of data.


Does AES-192 provide better encryption than AES-256?

Related-key attacks are interesting mathematical properties of algorithms, but have no practical impact on security of encryption systems, as long as they are used for what they were designed, i.e. encryption (and not, for instance, as building blocks for hash functions).

Bigger is not necessarily better. There is no practical need for using a 256-bit key over a 192-bit key or a 128-bit key. However, AES with a 128-bit key is slightly faster (this is not significant in most applications) so there can be an objective reason not to use bigger keys. Also, AES-128 is more widely supported than the other key sizes (for instance, outside of USA, AES-128 is available by default with Java, while bigger key sizes must be explicitly activated).

None of AES-128, AES-192 or AES-256 is breakable with today's (or tomorrow's) technology (if they are applied properly, that is). Try to work out what 299.5 is: it is... somewhat large.


Where is the best place to get descriptions of malware?

Try these links:

Timeline of computer viruses and worms
Timeline of computer security hacker history
Securelist - Descriptions
View Recent Malware


XSS in GET request not decoded on backend

Your analysis is incorrect.

Not all browsers do that, as some googling spits out an excessive blog post that seems relevant.

The blog post is old and IE is old, but this should be enough proof that not all browsers encode this, as you expect.

So: it is a real vulnerability, it poses a thread to your users.


MSFvenom doesn’t generate raw shellcode output properly


In standard terms (i.e. FIPS 46-3, which defined DES and 3DES from the US federal point of view [withdrawn in 2005...]), 3DES is a "kind of DES". So it is possible that by claiming "DES support" your VPN software actually implements 3DES. I am now assuming that you have checked that point and that the software in Android knows only of the original DES, not 3DES (which is kind of surprising for an OS as recent as Android 2.1, but who knows).

Cracking a DES key is feasible but not easy. This is a 255 average work factor. It has been done with specialized hardware (the EFF "Deep Crack" machine), then again with standard PC and other contributed machines (but a lot of them). An FPGA-based generic engine has been demonstrated to cost about 10000€ and to be able to crack a 56-bit key in less than a week (on average). So one has to assume that in a corporate setting (assuming that the "attackers" have huge incentive to discover trade secrets) a VPN protected by a 56-bit DES key can be cracked.

Still, using smartphones to access sensitive data over the VPN strikes me as a much weaker security point. Smartphones are used in unprotected environments (that's the point of having a mobile system...) and are possibly the most frequently stolen object these days. For a determinate attacker, using a FPGA machine is not very expensive -- but mugging the smartphone owner with a 5$ wrench even less so, and, lo! the attacker gets a free smartphone afterwards). If the VPN gives access to anything sensitive, then letting people use it from smartphones is a kind of offence.


Filling out ssn on a web form for printout purposes

I Am Not A Lawyer.

IMHO, what matters here is the possibility for the SSN to be sent over network via you web form and captured. For example, if the SSN is an input field in a form that is used to upload other data, it may or not matter whether the SSN is or not processed by your application. One may argue that your application sending it unnecessarily is an exposition of sensitive data.

SSL is probably enough, but as you do not intend to use it, just do not transmit it. A simple way to have a printable form that will never be sent over network is to use a form with no sending button and an explicit invalid sending address. For example, a form ation URL like "http://127.0.0.1/INVALID_DO_NOT_USE" could be an additional security, even if it is rather hacky...

But my advice here would be to use a PDF form. If all you want to do is to print the form, PDF has two nice points:

by default it has no provision to be automatically sent over network
it gives you better control of the printed document


Sensitive data in public wifi networks with https

This depends on the website and wether it enforces https with the right TLS version and correctly so (And has been visited before or is in the users HSTS preload list).

If not, a man in the middle could use a so called “downgrade attack” and not only read the traffic but manipulate it.

The thing with unencrypted public WiFi is, that a man in the middle position becomes feasible for everyone in close proximity, even relatively easily.

With such a position, many attacks that otherwise wouldn’t be possible become viable.


Risks and strategies to implement anonymous storage of Google Cloud Messaging tokens?

I would suggest using String m_androidId = Secure.getString(getContentResolver(), Secure.ANDROID_ID);

This will give you a unique ID, that require no permissions, that does only change during factory reset, and can be used to track so nobody spams the database. I would also suggest hashing with a app-specific key.

However, you still need to have any throttling to prevent someone from creating malicious entries. A good idea could be requiring the solving of a captcha to submit a "new" ANDROID_ID string that does not exist in database. This can be solved with a WebView and using Google Recaptcha, upon first launch of the app, combined with IP-based throttling.

Do remember that many cellular operator NAT's lots of customers behind one IP, so guard the logs carefully and if you see the app being popular and be prepared to increase the throttle limits incase your app start being more popular.

This could be implemented automatically by having a AI, that will compare the median request rate for all IPs to a specific rate, and only block if the rate is considered higher than this.
Median request rate is in other words, the request rate that is the average of the request rate of all IPs, but with the "low-balls" and "high-balls" removed.


How to connect a Raspberry Pi IDS to the home router to detect intrusions network wide?

If you want to passively monitor the whole network a monitor port on the router or similar would be sufficient - although most common home routers (the ones with WLAN and cable/DSL modem in it) don't have anything like this.

If you want to monitor data and also actively block traffic the IDS has to be in the path of the traffic. This means it either needs to be setup as the gateway for all systems in the internal network and then forward the traffic to the router, or the router remains the gateway but the IDS is between the router and the ISP. In the latter case the Raspi needs to care about the ISP connectivity too, i.e. it needs to have the physical ability (which might require a DSL, cable or FFTH modem depending on the kind of connectivity to the ISP you have) and also have the login information, can speak PPPoE or whatever protocol is required for the ISP etc.

So your current idea of setting up Raspi as the network gateway is likely the easiest to implement way. But, as Josef noted in a comment: it should be setup in a way that users simply cannot bypass the IDS just by changing the gateway. This would be best achieved by having the router/modem physically behind the Raspi so that no internal system could be directly reach it and thus the only way for any internal system to the router/modem and then to the internet is through the Raspi.


How does one properly check foreign USB Drives before getting them in your Network? Is the presented approach considered "safe"?

I would suggest going for the raspberry route. But instead of requiring administrators to perform the action, this could be constructed as a self-service station instead, of course locked with high secure locks and such too.

As the raspberry pi is not x86 it cannot run malware destined for windows, linux or mac PCs at all. It can run malicious scripts, but thats another thing and can be blocked.

Configure the raspberry pi to have a touchscreen, so the user can select files he want, and then make sure to block all keyboard access.

Now to the trick that will make this completely safe:

1: First, you restrict the interface to only show files of specific permitted file formats. For example (jpg, png, gif, tiff, svg, bmp) (doc, pptp, etc).

2: For pictures, you can use GD to convert from all known image formats, to PNG: (even PNG->PNG). This will strip off any malicious data that can be contained in these files, as only the raw picture data is copied over, not any metadata. (Note that you need to convert the picture to a plain GD object first)

3: For Office files, you use a Macro stripper, to strip off any macro data, and then use a document converter to convert from DOC->DOC, PPTP->PPTP etc. You don't need to use CIRClean, theres other macro strippers that can be used.

The reason you should use a converter to convert to the same format as the source format, is that such conversion will still require that the file contains valid data for that format, so for example renaming lets say virus.exe to virus.doc, will render a empty output file in this case.

This will completely cleanse the files. And this are also immune to "BadUSB" attacks as long as you configure the raspberry pi to not accept keyboard input. Mouse input will be mapped to the touchscreen, which have a very limited interface to select files.

To prevent any malicious USB from leaking secret data, its advisable to only allow copy in one direction, from USB to home dir, NOT the other way around.

So here comes the complete idea:

The user walks up to a self-service USB terminal (that is scattered around on the hospital). Insert his USB, on the touchscreen, the user selects the files he want. He can only see files of permitted file types.
After that, the files selected, are cleansed, and then copied to his "home folder". The login could be done with smart-card.


Visiting HTTPS pages over VPN = double encryption?

Yes, from your computer to the VPN exit node the communication will be "double encrypted". Then, from the VPN exit node to the destination it will only be encrypted by HTTPS.

So why is this important - isn't one layer of encryption in HTTPS enough on its own? It is impotant to remember that HTTPS does not encrypt everything - the domains you visit are still in plain text by necessity, and so is your DNS traffic. A good VPN takes care of that by encrypting everything. As a result the already encrypted part of the HTTPS traffic gets encrypted again.

(And if you would send an encrypted file over HTTPS through a VPN it would be tripple encrypted.)


Any MITM tool for forcing weak SSL cipher suite?

What you are trying to do will be... difficult. The main point is that at the end of the handshake, client and server send each other Finished messages, under the protection of the just-negotiated algorithms and keys; and the contents of these messages are hash values computed over all the previous handshake messages, including the ClientHello and ServerHello. What this amounts to is that if the client and the server do not see the same ClientHello (because you altered it in transit), then the Finished message contents will not match and the handshake will fail.

In order to successfully alter the ClientHello, then you must break the encryption right away, and not offline: you have to recover the encryption keys at the end of the handshake and before forwarding the Finished messages, so that you may adjust the contents.

40-bit encryption is within the realm of the technologically feasible. A first problem is that with export cipher suite, the 40-bit key is only an intermediate key; the final key is expanded to 128 bits. Brute force is still feasible, but precomputated tables (rainbow tables...) are not. A bigger issue is that since you must adjust the contents of the Finished messages, you must not only break the encryption keys, but also the MAC keys -- and these ones are big (128 bits).

Your only remaining option, then, is to break the RSA key used by the server. Theoretically, with TLS_RSA_EXPORT_WITH_RC4_40_MD5, the server's public key should have size 512 bits at most. A 512-bit RSA Key is breakable, but that's still quite an endeavour for an amateur. It has been reported that a single desktop PC can achieve it in two months; more recently, some guy factored a 512-bit RSA key for 75 dollars in three days (75 dollars worth of rented CPU). If you try yourself a connection to the server with a client (e.g. OpenSSL's command-line tool: openssl s_client) which claims to support only TLS_RSA_EXPORT_WITH_RC4_40_MD5, you will see the certificate sent by the server. If the server's public key is 512-bit only, then you can envision to break it. Note, though, that it is entirely possible that the server does not honour the restriction to 512-bit keys for "export ciphers" (since the said export regulations have been lifted more than a decade ago).

If you can break the server's RSA key, then you can impersonate the server, i.e. use the server's own certificate (necessarily valid in the eyes of the client) for your Man-in-the-Middle attack. If you cannot, and there is no way for you to build a fake certificate that the client will accept, then I don't see any way to achieve what you want to do.