Why do people use IP address bans when IP addresses often change? Why do people use IP address bans (e.g. to block a malicious user from an internet service) when IP addresses change often?

For example, we turn our router off every night so our IP address often changes in the morning. Furthermore, often a simple power-cycle is enough to change the IP address. Thus IP address bans are relatively ineffective.

On the other hand, banning IP addresses can cause a lot of grief for innocent users who are using the former IP addresses of a malicious user, and sometimes a range of IP addresses is banned thus causing the banning of innocent users to affect even more people.

So why are IP address bans still used?

P.S. I am referring specifically to long-term bans. I perfectly understand the advantages of short-term bans e.g. to put a block on a spam or DoS attack, or other situations where briefly disrupting the malicious traffic is beneficial.

IP address bans have flaws as you mention, but I think the primary reason they are used is simply that there aren't really any better alternatives. Other identifying features, like browser user agent, cookies, browser fingerprint, etc. are even easier to spoof or circumvent. There are plenty of extensions you can use to change your user agent or fingerprint, and cookies can simply be cleared.

  For example, we turn our router off every night so our IP address
  often changes in the morning. Furthermore, often a simple power-cycle
  is enough to change the IP address. Thus IP address bans are
  relatively ineffective.

The ease with which you can change your IP address depends heavily on the ISP. For instance, back when I had Verizon DSL, my IP address would change each time I turned the modem off and back on just like what you describe. But after switching to Comcast, my IP address has not changed for the entire two years I've been with them, even after multiple power outages and modem restarts. So the "router reboot" workaround won't necessarily work for everyone.

Another thing you should consider is that even if you're one of those people who can change your IP address with a reboot, you're likely still getting an IP address from a fairly limited pool of addresses. This is because ISPs generally don't assign addresses completely randomly; they divide their service area into smaller areas (e.g. neighborhoods), and then allocate a small range of addresses to assign to customers in each area. So if there was a really persistent and problematic user, a site administrator could ban the entire address range (though this could cause significant problems for other users as you mention).

Side note: It's worth mentioning that there are other ways of masking your IP address that get around this problem, like using a VPN service or Tor. Some sites, like Wikipedia, try to block all IP addresses of known public proxies to counter this.

  On the other hand, banning IP addresses can cause a lot of grief for
  innocent users who are using the former IP addresses of a malicious
  user, and sometimes a range of IP addresses is banned thus causing the
  banning of innocent users to affect even more people.

Yes, IP address bans are a blunt tool and this is one of the problems inherent with them. This is especially the case when an IP address is shared by hundreds or thousands of users in the same building, or even a large part of an entire nation via carrier-grade NAT. It is the responsibility of site administrators to minimize the effects of IP address bans on legitimate users. Various measures can be taken - for instance, you could make an effort to identify IP addresses are shared and make sure those IP addresses are only banned for short periods, or make it so that users with a certain minimum reputation can still log in from banned IP addresses and remain unaffected by them. If done right, IP address bans can be very effective at blocking unwanted users while having minimal impact on legitimate ones.


How to hide webresource.axd and scriptresource.axd file? I am getting an email from the security team, saying that webresource.axd and scriptresource.axd are visible. How do I hide it ?

This question seems more  to fit in stack overflow.

However you can remove those files by adding following to all my web.config files

<httpHandlers>
        <remove path="WebResource.axd" verb="GET"/>
        <remove path="WebResource.axd" verb="POST"/>
        <remove path="ScriptResource.axd" verb="GET"/>
        <remove path="ScriptResource.axd" verb="POST"/>
 </httpHandlers>

Now when you try to get these pages you might be prompted to login or given 404 error.

Also remove them from  in

<system.webServer>
     <handlers>
         <remove name="ScriptResourceIntegrated-4.0"/>
     </handlers>
</system.webServer>

<location path="WebResource.axd">
 <system.web>
<authorization>
 <deny users="*"/>
 </authorization>
</system.web>
</location>


CCM instead of key wrap Is there any instance of NIST or other encryption standards using AES-CCM to encrypt/authenticate key data?  I would like to use CCM over a keywrap function, but cannot find any precedent for this in cryptography standards.

If by design I guarantee that:
(1) Nonce data will not be reused
(2) The encrypting "transport" key will not be available to users for the encryption/decryption of non-key material

Are there any security vulnerabilities that make CCM a bad choice?

The Wikipedia article on Key Wrap states:

  Goals (3) and (5) are particularly important, given that many widely deployed authenticated encryption algorithms (e.g., AES-CCM) are already sufficient to accomplish the remaining goals.

Which suggests AES-CCM is an adequate, if inefficient, solution.


How to ensure wildcard certificate private key security? The time has come for us to renew and update our wildcard certificate. I've been tasked with researching the ways we can protect the private key without compromising the security of the certificate. (With the key and cert together, anyone could impersonate us.)

I understand the pros and cons of using wildcard certs, and this is the direction the IT Director has decided to go.

We're a 99% Windows shop; no configuration management setup. We're likely going to have to touch each machine that uses the wildcard cert.

I know some configuration management tools (like Puppet) have modules that you can use to pass a secured variable instead of a clear text password. Is there a way to install the cert on machines without having to distribute the private key to other team members?

Any thoughts/ideas/best practices would be greatly appreciated.

I'd configure a reverse proxy with SSL decryption capabilities. Therefore the cert is put in a single server and it terminates the SSL/TLS connection.

Your private key will only be on one server and you'll also have the ability to inspect HTTP traffic using a IDS/IPS.


MITM and https for authentication If I want to go to https://www.example.com, can my ISP instead give me a different https website instead but make it look like it came from https://www.example.com If they do, will my browser tell me that I have the wrong website and if so, is that true for all of IE, Firefox and Chrome?

If you connect such domain the certificate is checked by your browser. The certificate of the HTTPS server must be signed with one of certificate of certification authority your computer trusts. If it is not signed by it you will see warning from your browser the connection can't be trusted.

If ISP will be able to manage the certificate is signed by one of these certification authorities (or add another certification authority to your trusted certification authorities) you will not be able to notice it until you know, what CA issued the correct certificate for the server and you will check it manually in the browser.

This will never happen under "normal" conditions as public certification authorities will never issue certificate to anybody else than the server (domian) owner. And in order the ISP is able to install another certificate to your trusted CA store they have to somehow hack your PC or provide you a malicious code in some way (i.e. they give you a CD with some "drivers"). But its not that easy as it seems and I would say no ISP will risk something like this.

Edit:
I forgot to mention that is server will use insecure protocol (i.e. SSLv2) with insecure encryption suite there is also possibility the MITM can happen.


Can wildcard certificates hide/obscure the hostname in a TLS connection? I'm trying to increase security for my cloud-based / multi-tenant environment.  I'm considering having clients access an obscure URL such as GUID.myCloud.com.  I will then respond to that guid-based request with customer-specific data.

Considering that the certificate itself has a Subject name of *.myCloud.com, does that mean that the TLS protocol itself won't expose my private hostname?
Is there any reason to believe that Subject Alternative Names would behave any differently?

You'll still see server names in client hello SNI extensions.


Secure data by encrypting and rewriting on same file I'm working on a project to Encrypt files using AES encryption with a key generated from SHA-256 from a keyword.

My idea to claim this was to

first : read all bytes from a file

second : encrypt bytes

third : write encrypted bytes on same file

I had some reasons to write encrypted bytes on same file. one was to prevent data recovery. as far as I know, the standard way to do this is to write encrypted data on new file and then remove old file. but I know old file can still be recovered and thats the problem "If old non-encrypted data can be recovered, what is the use of encryption?"

In my experience, I could always reach last version of files when I recovered them, not the history of file changes.

for example I have text file with "This text" in it, and I change it to "This text is changed". When I recovered my files, I could just see a text file containing "This text is changed". (Can old version still be recovered ?!) . so this became my logic to rewrite encrypted data on same file which I'm sure its too risky and buggy !! but would this fulfill my wish ?

I've posted my codes and logics in stackoverflow here .
Then answers made me search more about data recovery. I also could read this article about data recovery. If I'm not wrong, file systems on HHDs will just remove a pointer to the file not the file itself so it can be recovered. Thats where I thought I have to rewrite on same file but answers in stackOverFlow told me its useless.

So can you give me details how I can at least HELP preventing old and non-encrypted file from being recovered ?

Also same article wrote something about SSD hard drive, which I think might be my answer (I read if I rewrite data on SSD hard drives it might be completely unrecoverable). How would I do this ?

Thanks.

Any information about how can I overwrite the left space (in case I change my output and write encrypted files to elsewhere) and preventing data recovery could be helpful.

FYI: I code with JAVA... examples can help me too

Most encryption software like bitlocker or Truecrypt will offer you to overwrite the space that's left with random bytes, resulting in the file being deleted.

Another option is using a fileshredder. Look for any shredder using the Gutmann method


Does entropy apply to passwords generation when some passwords are more likely? Entropy is a standard measure of the complexity of a password generation. The standard way to calculate entropy is to take the probability p of a password being generated and take the sum of p*log2(p) for every password in the set of possible passwords.  This entropy measures complexity based on how the password is generated or a worst case attack (e.g. we're not trying to calculate the entropy of rolling 6,2,6,3 on a loaded die, but the entropy of the distribution that led to those numbers getting rolled).  Entropy here is not measuring how the password would stand up to brute-force, etc.

However, for passwords with patterns (non-uniform distribution) Shannon entropy's not an accurate measure of guessability, since two random numbers can have the same entropy but one can act much more predictably if they have different distributions.  When the entropies are similar, the distribution with the least uniform distribution (the least random-looking) is always less secure.

For example, consider the following schemes with the same Shannon entropy but different security levels: flip a coin repeatedly and count the number of tails you get, stopping when heads comes up first.  Looking at the probability distribution, the numbers generated here has a Shannon entropy of 2 bits.  Great! That means this scheme is as secure as two independent coin flips, right?  Not quite.  If you think about it 50% of the numbers generated in the first scheme are 0 (heads on the first flip), and you have a total 1/3 chance of two users getting the same result using the scheme.  Two independent coin flips, on the other hand, gives a 1/4 chance of producing each number, for a 25% chance of two users getting the same result. (The math for calculating the probability of such a collision is not complicated but requires you to know the frequency of each possibility, as explained here).  Entropy gives a misleading figure for the security of the first scheme.

What happens when a password is generated using a random process that does not use a uniform distribution, or a distribution that's not easy to describe with or map to equally likely outcomes, like say:

A scheme to pick long phrases taken from a large English corpus
A scheme to generate a mnemonic-based password
Rolling a loaded die 15 times

How do you compare the strength of random but non-uniformly generated passwords like these to passwords generated from uniform distributions? Does entropy apply? Is anything else a widely-accepted substitute? In my experiments entropy isn't completely accurate but still gives a rough estimate of password strength.

I'm also not asking how entropy is calculated (I already stated that above), whether we apply entropy to the individual password or the distribution, or about the entropy of passwords made up non-randomly by users. Unlike the answer that says that it all comes down to "what dictionary is your password in" (which is cited as a reason for being a duplicate), this question assumes the distribution is not uniform, or in other words each password is not equally likely. I'm also not asking about the security of these systems and am well aware that patterns make passwords weaker.  I'm trying to understand the best way to quantify the security of these schemes to answer questions like this one.

Note: This question was closed as a duplicate, although some of this question isn't accurately addressed by the linked answers (e.g. how do you calculate the strength of a 4-word passphrase where the phrase is taken from the COCA corpus?) I've edited the question to address these points. If you think this question should be reopened please vote to reopen it, and if you think this question would be better if made more specific please say so.

The problem lies in the fact that you are considering a single password (i.e. one sample from a random distribution) alone rather than the full scope of possible passwords. When using information entropy as a means of quantifying the difficulty of a brute-force attack, we are interested in the latter.

What you describe as entropy is actually the information content of a single event. Entropy applies over the entire distribution and is sum{-p_i log_2{p_i}} for all i in the space of possible passwords. When considered like this then the uniform distribution has, as you correctly pointed out, a greater information entropy.


What does setting Unrestricted = false on PrincipalPermission supposed to do? I am doing some maintenance on a 10 year old ASP.net web-forms application. It has a business layer that has its methods protected by System.Security.Permissions.PrincipalPermissionAttribute, like this:

[PrincipalPermission(SecurityAction.Demand, Authenticated = true, Role = "2,3", Unrestricted = true)]
public void Foo(int bar)

A custom IIdentity and IPrincipal are used. The custom principal implements  bool IsInRole(string role) and interprets the role parameter as a comma-separated list of roles to check against.

I assume this once all worked just fine, but, currently, the IsInRole method is never called.

Of course, my attention was drawn towards the unrestricted-property. The MSDN documentation does not clarify a lot. I just tried with unrestricted = false and lo and behold, the validation sprang to live.

As far a I can trace back the code, the parameter unrestricted has always been passed as true. So, I am hesitating to just changes this to false everywhere.

Does this property really has the effect of saying:

  "Hey, I am declaring permissions here, but actually, never mind and just go ahead."

Or is is something more subtle?

It's not more subtle.

Setting Unrestricted = true means it will match any principal, and so setting the Authenticated and Role properties is pointless, because once the framework sees Unrestricted = true, it will always set Authenticated = true and Role = null and the demand will always succeed, regardless of the the principal.

So, it sounds to me like setting it to false (or simply removing it from the attribute altogether) is indeed likely what you want to do.


What does enable-static-engine do in Openssl ./config I am using a command to compile OpenSSL from source. I need to remove un-needed parameters that enable settings I do not need. One of the settings:

enable-static-engine

What does this parameter do?

How can I get the help of ./config? I tried ./config -help but that does not display the ./config parameters.

From the README, which is the first thing you should read when compiling the software by your own:

 INSTALLATION
 ------------

 See the appropriate file:
        INSTALL         Linux, Unix, Windows, OpenVMS, ...

And, from the INSTALL file one should read according to the README:

  no-static-engine
                   Don't build the statically linked engines. This only
                   has an impact when not built "shared".

To understand what this means I recommend to read the section How do I build a "dynamic" ENGINE? in the README.ENGINE file. It is not trivial to understand, it is probably irrelevant for most users of OpenSSL and it is not about security but about programming, i.e. off-topic here.


What difference between AES_128_GCM and AES_128 and AES_128_CBC ciphers? I encountered AES_128_GCM cipher, tried to find it in specifications of TLS1.2 and nothing, any mention. Could some one explain the difference between AES_128, documented AES_128_CBC and this new kid AES_128_GCM ?
Also, have .NET  System.Security.Cryptography any AES_128_GCM build in classes ? I don't see no one.

AES 128 is the AES block cipher, using a key size of 128 bits. It doesn't specify the block mode in which it is being used.

AES 128 CBC is the same cipher as before, in this case using it in Cipher Block Chaining. (Complete description of CBC in the NIST recommendation).

AES 128 GCM is again the same cipher, used in Galois Counter Mode. It is important to note that GCM mode also provides authentication of the data (it is a mode for "Authenticated Encryption").

If you want to get a general idea of the different block cipher modes, you can check the entry in Wikipedia. For a more detailed explanation, you can check the website of NIST with all the proposed modes for block ciphers: NIST Block Cipher Modes


"Flow" between computers (Logitech mouse) Logitech (and possibly other) mice offer a feature called "flow": mouse can pair with uop to 3 devices (PC, handheld, ...), and can mark, copy & paste content (even files) between these 3 devices (according to the description, not bought yet).

This would make life much easier for me, since some content is always on another device, but also expose all devices to threats on the weakest device.

In my understanding this implies that

[ the mouse has internal memory (hoping it does not use "external" (foreign cloud) memory) - sorry, learnt that content seems not to go primarily via mouse but via network between computers]
the (network-forming) software has decrypted access to all content (even if the mouse uses encrypted wireless communication)
even scarier, this risk is not limited to the said product, since a manufacturer may simply not (yet) disclose the functionality.

How would I make sure (or limit the risk) that the mouse or driver software (on the weakest device...) does not share the copied (or any other!) content with someone else (Manufacturer, or - if hacked - to anywhere)? Specific questions:

Is anybody aware of such attacks existing?
Which reasonable measures can be taken (besides standard practice like keeping software, drivers and antivirus up to date, avoid "risky" internet
sites and software from unsecure sources)?
How does standard antivirus software (Kaspersky, Norton, Avira, ... - which ever you use, I am looking for experience) handle this software that establishes kind of "unusual" network traffic? Ignore it anyway, scare the user each day by warnings, or useful monitoring?

This question is not about the risks of wireless communication.

For existing known vulnerabilities look here
From Logitech site:

  Logitech Flow requires computers that can connect to each other over a local network

So Logitech software is the app you need to trust.

Make sure to connect the mouse to the most secure workstation, because this pc will be the server for all the rest. If it gets compromised - an (very advanced) hacker has a potential access to the other clients.

This traffic is not exactly 'unusual', dropbox for example is much more unusual than that. If the traffic is encrypted - most of the antivirus will not inspect that at all. By definition Antivirus should care about app activity inside the pc, not about network traffic, that inspection should be done by firewalls. Only after you "copy" a file into a pc - an antivirus on active mode should check the files you copied.

P.S. I didn't check it by myself - but if you will try to use this app on OSX while the mac is used as client - I'm pretty sure you won't be able to approve privileged messages.


Could the Stack Overflow Dance Dance Authentication April Fool's joke actually work in a real environment? Today, Stack Overflow released their April Fool's joke (a day early, but hey) involving Dance Dance Authentication.

Essentially, it's logging you in by dancing in front of your PC, and it can recognize multiple dance styles. The video is worth a watch, because it's hard to explain how this works.

Now, obviously, this is a joke, but could this actually somehow be made to work as a way to log in? And could this ever be secure?

Any analysis of a human's behaviour has the potential to be used as a form of authentication (keystroke analysis), but there are problems if you attempt to make it a primary authentication factor.

It is far better to use biometric characteristics instead of behaviour as there is less chance for change from attempt to attempt in normal operation. Fingerprints don't change throughout the day, but your enthusiasm while dancing (or typing) can wax and wane depending on your coffee intake.

At best, it might be possible to use behavioural analysis as a "confidence factor" where, if successful, could be used as a part of a second factor for authentication, but failure could not be regarded as a login attempt failure (i.e. not a login failure). Or, in other words, if it works, great, but if it doesn't work, provide the user an alternate authentication challenge.

The UX problems this presents upon failure are a real issue.

So, is it secure? Technically no because for it to be used as a reliable primary authentication method, it would have to be very permissive to allow for normal variations in human behaviour. But it could be used as an augment to provide a confidence factor for another secure authentication method.


How does IE's Privacy options affect javascript's ability to save cookies? I'm looking at IE's privacy options screen and am trying to figure out how it breaks javascript, workarounds to that, and how I can gracefully degrade my user experience.

Is there a guide that directly describes the IE reaction to the P3P header?

How about corresponding Javascript samples for each known good/known bad example?

I would say that, to the client-side programmer, it doesn't matter how IE privacy settings break javascript -- If you're going to support graceful degradation, then the cause of the javascript failure doesn't matter to the programmer. All that matters is that whatever caused the javascript to "break" the code can handle it.

In that regard, it sounds to me like you are wanting a list of things to do when programming javascript graceful degradation. This kind of question would belong in StackOverflow.com, but http://en.wikipedia.org/wiki/Unobtrusive_JavaScript has good information (including a "best practices" section at bottom).

If you specifically want to know how to do unobtrusive JS in regards to making sure your site is not dependent on cookies, then SO is still the place to ask that.

Also, P3P information does not affect the javascript (except for a few edge cases in MSIE (http://stackoverflow.com/questions/7707780/is-p3p-response-information-accessible-from-javascript/7707863#7707863)


Will evolving bio metric capabilities on mobiles replaces online transaction verification through SMS (OTP)? We are working on an online eCommerce site and we need to have online transactions. The common mechanism of verifying the online transaction seems the OTP (one Time Passwords) over SMS.

But this mechanisms is alarming as came across following vulnerability/exploit on SMS protocol.

https://attack.mitre.org/mobile/index.php/Technique/MOB-T1052

https://blog.easysol.net/ss7_sms_based_exploits/

***As per the second article even Telecoms have warned using SMS (insecure) for banking purpose.

Is there an alternative way of verifying online transaction through 'evolving mobile bio metric capabilities'?

Or Are there any other alternative we can adopt?

Biometrics are tricky for online transaction. The more feasible way would be to use something like TOTP. There is a variety of apps that support TOTP generation and it would be easy for you to distribute it (print out a QR code).

An even more secure but much more expensive alternative is to use physical tokens. I would strongly recommend to support them. While they are not feasible for everyone, you could at least support them for your security conscious customers (who have their own tokens) and possibly force them (provide a token) for premium customers who do large transactions regularly.

Also, invest in notifying your customers. A service where you send an sms or other notification about every transaction should be available (optional) and for suspicious (unusually large) transactions, they could be mandatory. Noticing a breach early could make it possible to stop the transaction before it goes through.


How to contact a tech company's CERT? Given I discovered a vulnerability in a product, e.g. a networking product, and can't find the email address of neither their CERT nor a disclosure contact, how should I report the vulnerability? Should I contact the first level tech support and ask for the address? Should I send them a problem description and hope the ticket gets escalated?

As requested, I'm making this an answer:

You could either

contact your countries CERT
contact the CERT of the manufacturer's country.

Hopefully, they will forward the information appropriately.


How to get session info out of encrypted .NET viewstate? I am performing a penetration testing for the first time in a .NET application that instead of providing cookies for session management uses the viewstate hidden field.

I am using the .NET Beautifier plugin in BURP in order to decode the value of the viewstate parameter but it says that it is encrypted and it cannot be decoded.

The ASP.NET version is 4.0.xx. Does this version always encrypt the VIEWSTATE with a key stored in the server?
 How secure is it?

Firstly, VIEWSTATE is a value to control the state of a view, it helps to keep data on view level and prevent Cross-Site Request Forgery (CSRF), in others words, this value is used to authenticate requests - sending data to backend and being sure is a legitimate request - , so it has the following features at least:

it's a secure pseudo-random value.
it's long.
it's unique for every view.

Maybe, you could decode this value, but it is just a pseudo-random value. Now, answering your question: yes, this value is secure, but it should be used to authenticate requests (prevent CSRF), but it shouldn't be used to authenticate users, because one of its feautures is to be unique for every view, then its life time is shorter than a session's life time, so don't confuse the purpose of VIEWSTATE with a session management.

I hope this information helps you.


What happen when a local device have the same IP as an external website When I enter 'google.com' in my web browser, my computer goes to the DNS server and gets Google's server IP address, then it look for that address in the local network and when it doesn't find it it goes to the gateway and off it goes.

My question is, if by any chance there was a device in my local network that uses that IP address, would my machine go to that device?

That would be a problem in the protocol because now its easy to go in a public network and set a static IP for my device and trick other people in the network that I'm the real Google website. I think that there's something more to it so this doesn't happen but I haven't been able to find an answer.

The short answer is no, this would not happen.

The reason is that if you change the IP address of a machine to say $172.217.20.28$ (the result i get when doing a DNS lookup for google.com), the machine would belong to a different subnet and therefore not be visible to other machines on the physical network.

An IP address consists of two parts: a network identifier and a host identifier. The $n$ most significant bits specifies the network part and the $32-n$ (for IPv4) least significant bits specify the host, where the number $n$ is given by the subnet mask.

Suppose the machines on your network use a subnet mask of $255.255.255.0$ then the $24$ most significant bits of the IP address specify the network, meaning that only machines that have IP addresses that are identical in the first $24$ bits are considered to be on the same network.

For further info i would suggest reading about subnetworks and routing .


Timestamp vs Replay attack 1) A → B : username, timestamp, h(password)

2) A → B : username, h(password), h(timestamp)

Can above two formula prevent from suffering replay attack?

I think 1 is immune from replay attack but i am not sure about second one.

Can any one help me?

None will protect against a replay attact.

In the first case, all the attacker has to do is adjust the timestamp.

In the second case, since H() is not supposed to be secret and since the timestamp is known, and attacker can also adjust the request by creating a valid H(timestamp). There is also the problem that you need to synchronize the client and server so that they both have the same timestamp value.

The best way to prevent replay attack is to use challenge-response (there are other ways to do that, depending on your needs).


Why does Chrome claim that this stylesheet violates the Content Security Policy? I have a website in which I include several CSS stylesheets from my own server and one stylesheet from a remote server.

I wanted to write my Content Security Policy in a way to permit all local stylesheets, and only this one specific remote style sheets. This was my attempt:

style-src 'self' 'sha256-L/W5Wfqfa0sdBNIKN9cG6QA5F2qx4qICmU2VgLruv9Y='

However, upon navigating to my website, Chrome 78 claimed that the remote stylesheet does not match the existing Content Security Policy and refused to apply it. I looked at this similar question, where the solution was to apply 'unsafe-hashes', which did not solve my problem. It seems as if there is a difference between an externally included script and an inline script.

So my question is: Why does Chrome claim this script is not allowed? And what do I need to allow this script? (Aside from a generic whitelist for the domain)

From the documentation of style-src:

  '<hash-algorithm>-<base64-value>' A sha256, sha384 or sha512 hash of
  scripts or styles. ... In CSP 2.0 this
  applied only to inline scripts. CSP 3.0 allows it in the case of
  script-src for external scripts.

So based on this the hashing specification cannot be used for external styles but only for inline styles. The behavior change with CSP 3.0 only allows external scripts this way but not external styles.


MD5 PPPoE chap crack My apartment complex uses PPPoE CHAP authentication for internet (Mikrotik router), I want to switch their provided router with my own, however they aren't willing to give me my password.

I have fooled the router by connecting it's WAN port to my computer and running a PPPoE server on it, however, the router does not answer PPPoE PAP requests, so I am unable to recover the password that way.

That said, I can provide any PPPoE CHAP id and challenge value, and the way I understand it, CHAP uses MD5(id . password . challenge), are there any id and challenge values I could provide that would speed up cracking it via hashcat?

Probably Not Feasible

Background

In CHAP, the authenticator sends a challenge, and then the client responds by hashing the secret plus some other data from that challenge.

This is comparable to sending a new salt every time, and it does not represent the scenario hashcat was designed for.

That said, the response contains an MD5 hash of challenge ID + secret + challenge value. Two of those values are transmitted over the wire. The resulting MD5 hash is also transmitted, so you have everything you need to recover the secret in theory.

The problem is getting the existing tools to work in this scenario.

Methods

You could take three approaches.

You could generate a wordlist consisting of randomly-generated secret candidates and concatenate them with the ID + challenge using rules. (Extremely slow)
You could create custom character sets for each character in the ID + challenge and run a bruteforce mask attack. (Fairly slow)
You could attack similar to option 1, but with a regular wordlist; however, this will only succeed if the secret is in your dictionary. (Fairly fast)

Expectations

Typical CHAP secret lengths are 12-16 bytes/characters. You could probably run #2 for 8- or 9-character secrets in a reasonable time frame, but longer secrets would be problematic even with high end hardware. You are looking at years, even with dedicated multi-GPU rigs.

This leaves #3 as the only feasible option, which means your efforts are tied directly to the quality of your wordlist and the CHAP secret.


Confusing about Ephemeral Diffie-Hellman 1 Does Ephemeral Diffie-Hellman support authentication?
Quote from www.rsa.com/products/bsafe/documentation/mesuite21html/dev_guide/group_EPH_DH.html

  Ephemeral Diffie-Hellman does NOT provide authentication, since neither party has guarantees about the entity with which it is communicating.

However, Quote from the book ,Cryptography Decrypted (Author: H.X.Mel), P225

  Fixed and Ephemeral Diffie-Hellman support authentication.

So, does Ephemeral Diffie-Hellman support authentication?

2 Which differences are between Ephemeral Diffie-Hellman and Static Diffie-Hellman?

Presumably, this is a follow-up of your previous question.

EDH differs from static DH in that static DH always uses the same DH keys.
In contrast, when using EDH, keys are temporary and re-generated every time (or their re-use should be avoided, at least).

EDH doesn't provide authentication on its own, but the fact that the server signs the content of its server key exchange message which contains "a Diffie-Hellman public key with which the client can complete a key exchange (with the result being the premaster secret)" implies that this DH public key is authenticated by this signature.

This is described in TLS 1.1 Section F.1.1.3:

  When Diffie-Hellman key exchange is used, the server can either
  supply a certificate containing fixed Diffie-Hellman parameters or
  use the server key exchange message to send a set of temporary
  Diffie-Hellman parameters signed with a DSS or RSA certificate.
  Temporary parameters are hashed with the hello.random values before
  signing to ensure that attackers do not replay old parameters.  In
  either case, the client can verify the certificate or signature to
  ensure that the parameters belong to the server.


Develop and test a vulnerable login system I'm a beginner on course to be an expert (hopefully) and I've been set assignments to test security systems on the web. The whole assignment is to prepare, test and document the results to correlate with real-life professional work. Coming from a software development background, I am logically solid on information security systems and how they work but I struggle with the practical side.

The assignment is to prepare and to pentest a login form by SQL injection. I also have a background in website development but never understood the backend of things. What would be the best way to develop a login form with a backend database that's susceptible to a sql injection (I'm a rookie so the easiest and most vulnerable login form would do)?.

Would I need a CMS? (This would all be in a sandbox environment)
Would I need a server for SQL?

In my opinion the easiest way to prepare and test login page vulnerable to SQL injection is without CMS, as follows:

Prepare a HTML web page containing a POST form with fields "username" and "password"
Prepare a DB with table "users" and columns "username" and "password". Populate it manually with a couple of plausible entries.
Prepare a PHP page that receives the POST and opens a DB connection searching for matching DB records where both values match.
Depending on whether a match is found you should return a different message and open a session or not.
Test the page automatically with the software SQLmap or OWASP ZAP and/or test it manually using a local proxy (e.g. Fiddler)

The pivotal point is that the vulnerable PHP page forms the SQL query by concatenating strings (this allows the attacker to forge the ending part of the query, bypassing login or extracting information from the DB). The non-vulnerable page should build the query using prepared statements. If you use a CMS then you should use its own login or anti-SQL injection security features.

A proper login page would also incorporate other security controls like account lockout, password hashing etc. but I think they are outside the scope of your exercise.


JSON Web Token Security RSA We are planning to use JWT (JSON Web tokens) in an application project, which is a set of multiple distributed web services allowing SSO authentication (single sign on). So there is a single central identity server which creates JWTs. Every call to any of the actual web services must be authenticated with a JWT previously obtained by the client from that identity server.

The following idea came up on how to use public/private RSA key pairs to limit security risks in key distribution.

The server has its own private/public RSA key pair. When creating a JWT, it signs it with its own PUBLIC key. The identity server keeps this "public" key private. But it distributes its "private" key to all services. When a client uses such a JWT with one of the web services, the service uses the "private" RSA key to decrypt and verify. Services do not need to contact the identity server for verification, which is one of the purposes of using JWTs in the first place.

In other words, the usual roles of "private" and "public" keys are reversed. This would allow to generate a new private/public RSA key pair relatively frequently, such as daily, to protect even against temporary security breaches on the identity server / seizing of hardware etc. Anyone in possession of the "private" key cannot generate fake JWT tokens on his own, because he does not possess the "public" server key. It does not even matter if anyone "steals" that "private" key - they can only verify tokens with it.

This has an advantage for single-sign-on scenarios: the client needs to get a JWT only once and can make multiple calls to all services allowing such a token without having to constantly re-authenticate. The token obviously would have a short life time such as 1 hour. It helps where multiple web services are required to get a single final output result. (We don't have the scenario where only 2 parties are involved where a server could use the public key of the recipient to encrypt.)

On first glance, this appears like an ingenious method of security JWT tokens. I could not find any reference on the web so far to someone implementing it this way. But I am sure someone else must have thought of this. It appears safe, on first glance at least.

Is there any experience or data which we haven't thought of which makes this scheme insecure?

I just happened to find this question here in 2018, and I want to warn those of you back in 2016 that this is completely insecure. Anyone holding your private key can indeed mint all of the JWT that they like. If this is an RSA key pair, it is almost certainly trivial to compute the public key, given the private key.

Given the public key, it is very, very hard to find the private key (hence, the strength of RSA). Given the private key, it is easy to find the public key. Just guess the typical exponent of a public key, and see if that works.


Allowing root login, but denying any actual logins A friend told me a few months ago about an audit where he discovered root logins were enabled via SSH. This obviously ended up on the report, but when questioned the admin told him that he had set up SSHD to allow root login attempts, but not actually check them, and just claiming the password is wrong, as a kind of honeypot.

How is this possible? A read of the docs of sshd shows no obvious way to do such a thing.

It is easy to construct a password hash that does not match any password. One of many ways to achieve this would be to store a hash value along with a different salt from the one it was computed from. A password hash constructed that way would never match an actual password unless you constructed a collision in the underlying hash.

Regardless of the method used to construct such a password hash, the outcome is the same. The account will appear to have a password (to any program with access to check this), but regardless of which password is entered, it would be rejected.

Whether this approach is a good idea is a different matter. I would rather have sshd simply refuse password logins completely.


Hosting a "Capture the Flag" style competition for fun and learning? A few friends and I want to run some kind of CTF competition in which we both have identical OSes that we can attack and defend as teams/individuals.

I was looking on the web and I found some good stuff like Metasploitable and some stuff on vulnhub.com

I'm basically looking for any advice as to what the best way to implement this thing is and whether there are any other cool goodies like the above mentioned.

How would you set this competition up? What would you make the goals? How much time should we have to secure the system and how much time should we have to attack? Any advice is welcome. We are very novice to computer security (but all work in IT) and just need an idea of how to start it and how to grade it.

The problem with Metasploitable and alike is that these are mostly for demonstration purposes and contain far too many vulnerabilities which also aren't easy to fix either. Also in a CTF, you don't want people to corrupt the complete VM but only get a token out of a single service.

I would suggest looking at the iCTF, they have some sample services. If you all are IT affine and do CTFs for fun and educational purpose, writing your own vulnerable services is a good idea. They can be simple web or CLI apps, there are extensive design guides on iCTF. They also have a complete framework for any kind of CTF.


What is the proper priority/mix of (people, tools and technology, processes) to optimize defense? I'm curious if people have different views on this and why.

Update based on comments:

Defend enterprises.

Quotes:
"Long-time blog readers should know that I don't rely on tools to defend my enterprise. I rely on people first, followed by tools, then processes", Richard Bejtlich

“The Enterprise Information Protection Paradigm,” Dan Geer’s [...] because it drives unification of people, process and technology.

"Surviving Security: How to Integrate People, Process, and Technology" by Amanda Andress

"Defense In Depth", as a philosophy, would suggest that you would integrate information security throughout the organization: in all functional areas, technology solutions, and business practices.  That said, such an approach has to be balanced.  Ultimately, the effort is going to be dependent on the organization in question.  The military, for instance, integrates "opsec" (operational security) to virtually all aspects of its operation, while a restaurant likely has no clue about security beyond what they're told to do by their card processor.

So, in the end, its going to vary on a LOT of factors.


How to implement machine tagging when allowing a user to "remember me" on web application? The remember me cookie should identify the machine as well. So by implementing machine tagging, we will avoid a situation when an attacker tries to login with the user cookie from another machine. Meaning, by creating machine tagging mechanism to remember me should invalidate the login associated with a cookie on a different machine.

What is the best way to implement machine tagging when allowing a user to "remember me"?

Also, what information precisely would you use to machine tag? I guess It is not enough that this information be unique; it also has to be unguessable to an adversary,

This question is not referring to understand how best secure the session but looking at long-term / persistent hold with parameters of identifying the user machine characters.

The problem with asking a machine to identify itself is that it can lie. If an attacker can steal a cookie, there is a good chance that they can also discover any information needed to impersonate that machine.

The only (partial) exception to this is IP addresses, but when you tie a cookie to an IP address you risk annoying users when their IP address changes. Unfortunately, changing IP addresses is quite common for smartphones or laptops, and may even happen regularly for a desktop depending on the ISP. IP addresses can also be shared by multiple users, so this solution isn't 100% effective. This is a trade-off between usability and security, so the decision will depend on the application.

In most cases a cookie with the Secure and HttpOnly flags is sufficient.


Learn Bash or Powershell for Security Work? Is Bash more commonly used in security work than PowerShell? If so, why? (Now that Powershell can be used on Linux)
I tried to Google around for an answer on this, and the only questions we seem to have here are quite different, e.g.:
What should I learn for Cyber security
https://stackoverflow.com/questions/573623/is-powershell-ready-to-replace-my-cygwin-shell-on-windows
I know this is dangerously close to "opinion based", but this question has concrete answers in other areas - for example Kali over Windows / other Linux implementations for OS, Python over C#/Java in terms of the most common languages for security, etc.

Is Bash more commonly used in security work than PowerShell?

Yes.  For example, github appears to have more Security sh/bash scripts than it has ps1 scripts:

Search Term
Hits

github security sh
14,100,000

github security bash
9,110,000

github security ps1
635,000

If so, why? (Now that Powershell can be used on Linux)

Rome wasn't built in a day.  People have been writing sh and sh-compatible scripts on Unix and Linux for 40 years.  Powershell may now be available on Linux, but it will still take quite some time for adoption to spread.


Is KeePass # of rounds relevant if you use a key file as master password? I used to have my database set to 20.000.000 key transformation rounds and it would be fast enough on my PC but I found it takes too much time on my phones so I went to lower it and couldn't notice this:

I use a key file as master password so as far I know, I'm safe from dictionary attacks on my master password correctly?

If so would be safe to set that for something like 10.000 just for sake of convenience?

The point of using the key file in KeePass is that you can keep the file out of reach (on external media) and connect it only when you need to unlock the database.
As you consider phones, you likely have no way of moving the key file outside of the regular filesystem. That in turn means it does not bring any security benefit. Refer to this guide, especially the "Location" section.
If you use composite method: password and key file, having the file on your phone nullifies the value added, so your assumption "I use a key file [ ] I'm safe from dictionary attacks on my master password" is false.
In effect decreasing the number of rounds for the password has the same effect regardless if you use the key file or not.

If you use only the key file, decreasing the number of rounds does not affect you security, as it is already zero.
Technically, according to the documentation, the key file is not subject to the multiple key transformation rounds, instead its SHA-256 is calculated only once:

When using both password and key file, the final key is derived as follows: SHA-256(SHA-256(password), key file contents)
(...)
To generate the final 256-bit key that is used for the block cipher, KeePass first hashes the user's password using SHA-256, encrypts the result N times using the Advanced Encryption Standard (AES) algorithm (called key transformation rounds from on now), and then hashes it again using SHA-256.


Secure way to store sensitive API details of users (localStorage or database?) I am playing around with the idea of creating a website for cryptocurrencies, where a user can sign up on my website, enter his API details for one of the exchange markets that I will support, which allows him to trade on that exchange, but using my “more user friendly” web interface.

My main goal is to create a more user friendly interface than what most exchange websites offer. I am not hooking directly into any cryptocurrencies or wallets, all I do is use the API of existing exchange markets, relay the information to my website, where I have a more user friendly interface.

Since this is a very sensitive subject in regards to security, I am trying to figure out, what the best way would be to store the API details of the users. In general I don’t like the idea of storing the API details on my database server, nor on my server in general. The thought of having my website hacked and all the API details being exposed is terrifying. Of course each exchange website that supports APIs has their own security built in, such as API sessions with 2FA, IP restrictions, weekly generations of new API secret keys, daily trading limits via API, and not allowing withdrawals of wallets via API. But damage can still be done if those API details get stolen.

I would prefer if there would be a way where I would not need to store the API details on my server at all, but rather have the user save them locally on his PC. That way he is in charge of keeping the API details secure.

This thought brought me then to the idea of creating a desktop app using electron (https://electron.atom.io/). That way I can still create the website the way I want, but it’s wrapped into electron, so it always run locally. Before I pursue this idea, I would like to keep investigating my previous idea of a regular website, as I prefer to have my website cloud based, SaaS, to prevent piracy.

So I wonder, storing API details of a user, without saving them on the server, what other options would I have? Cookies? Probably not secure. What about localStorage? https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API

Are there other options or am I too paranoid about this? Is it generally accepted to store sensitive API details on a database server along with the rest of the users details?

How about storing the API tokens in a way that not even you can use them?

Encrypt the API tokens with a key derived from the users password. To avoid having to send the password to the server in plain text you could use a hash of it as the key - making sure to use a different salt on the client side to the normal server password storage process. On login the tokens can be pulled from the database and decrypted. If the user forgets their password then the API details can't be recovered from your copies - but that is OK because they can get them and reenter from the exchanges again.

If taking this approach you want to take steps to make sure the tokens are not paged out on your server. There is little point going to this much effort to then have them written to disk anyway. You also need to ensure they are flushed from memory on log out.

Another alternative would be to derive and use the keys / API tokens on the clients machine - this way you never have access to them in plaintext. This assumes the Exchange APIs have CORS policies which allow your application to call them from the clients machine. An example of key derivation / use using the WebCrypto API (More complete code here - https://pastebin.com/XzrarRha)-

var _algorithm = "AES-CBC";
var _key_size = 256;
var _pbkdf_iterations = 100;

// Do not change this once used in production
// If copying from StackExchange replace with a new random value for your app
// or pass in a user specific value from the DB
var _defaultSalt = "af95a2b25229d227269a54fdec562d93";

// Derives a key from the given password.
// Salt is not required. If supplied should be a hex string.
function deriveKey(passphrase, salt)
{
    if (typeof(salt) === 'undefined')
    {
        salt = _defaultSalt;
    }

    return passphrase == null || passphrase.length < 10 ?
        Promise.reject("Password must be at least 10 characters") :
        crypto.subtle.importKey(
            'raw',
            stringToUtf8ByteArray(passphrase),
            { name: 'PBKDF2'},
            false,
            ['deriveBits', 'deriveKey' ]
        ).then(function(passwordKey) {
            return crypto.subtle.deriveKey(
                {
                    "name": 'PBKDF2',
                    "salt": hexStringToByteArray(salt),
                    "iterations": _pbkdf_iterations,
                    "hash": 'SHA-256'
                },
                passwordKey,
                { "name": _algorithm, "length": _key_size },
                false, // Extractable is set to false so that underlying key details cannot be accessed.
                [ "encrypt", "decrypt" ]
            );
        });
}

function encryptData(keyObject, data)
{
    let iv = crypto.getRandomValues(new Uint8Array(16));

    return crypto.subtle.encrypt(
        {name: _algorithm, iv: iv},
        keyObject,
        data
    ).then(function(encryptedData) {
        return {
            iv:iv,
            data:encryptedData
        }
    });
}

function decryptData(keyObject, iv, encryptedData)
{
    return crypto.subtle.decrypt(
        {name: _algorithm, iv: iv},
        keyObject,
        encryptedData
    );
}


Nmap scan of iPhone public IP address shows port 21 open I'm using my iPhone personal hotspot to connect to the internet on my computer via usb connection. I don't go through any other router or connection. The phone is my only means of connecting my computer to the internet. The phone is jailbroken.

I did a nmap scan of my public IP address and it shows that port 21 is open. Everything I've ever read has said ftp is unsecure shouldn't be used. So it seems strange to find this port open on a public ip address. I don't use ftp for anything (that I'm aware of.)

$ nmap -Pn xxx.xxx.xxx.xxx --reason

Nmap scan report for xxx.xxx.xxx.xxx
Host is up, received user-set (0.014s latency).
Not shown: 999 filtered ports
Reason: 999 no-responses
PORT   STATE SERVICE REASON
21/tcp open  ftp     syn-ack

Nmap done: 1 IP address (1 host up) scanned in 6.72 seconds

Is a public ip address exclusive to a single device or are there other devices in the cellular network sharing the same ip?
Is there any risk that someone could gain access to the data on my phone or computer through this open ftp port?
And if there is a risk, how would I go about closing this port?

Typically the IP is shared / NAT'd amongst many devices.
Yes it would be a risk if the port was actually open
It would most likely be opened by an app, so uninstall apps until the port disappears or restore back to factory defaults.


PCI compliance for bank card system There is a bank who has internal system working with card data preparation, generating PANs, and finally preparing personalization files that are sent to third party card manufacturer.

The bank can see in their internal system all PANs in clear text and they are not PCI compliant.

What should be the PCI compliance requirements for such use case? Can the bank be out of scope of PCI requirements?

Issuing banks are subject to a different set of standards than the PCI DSS.  See the PCI Card Production standards for their specific rules (use the pull down to select Card Production.)

Yes, banks are required to file a Report Of Compliance, and of course they certainly could be out of compliance.  Being out of compliance doesn't mean they close the doors, though.  Their assessor would need to see a plan to get them into compliance, and they could keep operating. But operating without a ROC means taking on a lot of risk:  they're betting heavily that they won't have a data breach.  If they do, the full burden of fraud will fall on them, as well as fines, penalties, and class action lawsuits from their customers.

Of course, any company that's breached gets re-audited, and the auditors who look at them after the breach always find some reason they weren't in compliance.  The PCI doesn't appear to be willing to take responsibility for deploying a weak or ineffective standard, just as they're unwilling to own their share of the responsibility for having forced the current insecure protocols and systems on the banking and retail industries.


NSA crypto Suite B - historical I'm looking for information on what NSA suggested for use in commercial systems in past times. 90's and early 2000's.

I'm mainly interested in PKI and symmetric cyphers for SSL and file/disk encryption.

NSA was undergoing a transformation on the subject question during the timeframe you are questioning.

In the previous two decades through the mid 90s NSA advocated for no strong privately controlled public encryption.  This position surfaced with their clash with MIT over the work of the famed RSA crew Ron Rivest, Adi Shamir, and Leonard Adleman resulting in the rushed publishing of same in 1976.  Federal funding for MIT was threatened during that dust up.  That position continued through the next 15 years highlighted by the flare up with Phil Zimmermann and PGP which almost landed him in prison.  By 1993 NSA was advocating the ‘Clipper Chip’ solution (using Skipjack) which created a back door key escrow for all public encryption.  The pushback against the concept was great from both academia and the common computer enthusiast.   That sets the stage for the period you question.

Times were changing as the Cold War ended, BBS-based personal computing was replaced by web browsing based on the Netscape browser with its PKI SSL solution, and with those changing times so changed NSA.  By July 2000 NSA had gone so far as to partner with Network Associates, the owners of Zimmerman’s PGP at that point, to create a free open source operating system – SELinux.  NSA by that point embraced publically available encryption as we know it today and provided hardening recommendations using same.  You can find specifics at http://www.nsa.gov/ia/guidance/security_configuration_guides/archived_guides.shtml .   Keep in mind that NSA was actually just joining the public using commercial standards of the day in the period you are questioning.


Why don't major browsers currently support TLS above version 1.0? TLS 1.0 seem to be vulnerable to Beast, Lucky13 and maybe other attacks and is simply outdated. Common workaround used e.g. by Google was to use RC4 which was also recently broken, but none of the major browsers seem to be implementing newer version of TLS, except Microsoft IE for newer Windows versions.

Is there a reason why there has been so little movement?

Edit: almost the same question. Why was it closed? Mystery on stackexchange.
Supported TLS versions at 2011-09-22

Do I think right that to avoid problems with TLS 1.0 you have to forbid it? This can take time.

I'll misuse my questions to answer Thomas Pornin because this doesn't fit into comment.

As usual, you write many letters :)

  "RC4 breakage is still "academic"

Do you remember WEP history? 2001 only certain key patterns were vulnerable which could be excluded without changing the protocol, 2004 it was no more the case and 2007 only 40k packets were enough. Attacks never get worse, only better. And in real life, all updates need time, years will past till all servers update, although it's not so much like on soho routers. Can you predict with reliable probability when it will become realistic? About workarounds - are they backwards compatible? How long will they hold? Isn't it easier to use newer TLS version?

  Upgrading client support to TLS 1.2 will not change anything at all until most servers are upgraded, too.

So upgrades need time, earlier we'll begin, earlier it's done.

  comparison with IPv6

Well, with IPv4 you can predict when you are out of IPs. This depends much of the country - those who were first in internets usually have no problems :) Those who are out of IPs advance IPv6, like China.

  In practice, several widely used browser rely on the SSL/TLS code of the underlying OS

Which ones O_o? I thought only IE does this, who cares about it with no working AdBlock.

The main reason why there is little movement is that the "breaks" are not practical enough to show up on radar.

BEAST does not work anymore. Firstly, it requires a way for client code in the browser (hostile Java or hostile Javascript) to emit cross-domain requests with a high level of control at the bit level; the two known ways to do that (a draft version of WebSockets, and a vulnerability in the Java VM implementation) have been fixed. Secondly, browsers and OS have added workarounds, namely the 1/n-1 split: whenever a TLS record is to be emitted, two records are sent, the first one containing only one byte of application data. This workaround prevents BEAST from being applied.
RC4 breakage is still "academic". It had been known for some time that RC4 had some serious biases. The recent results (March 2013) are some systematic measures which show that there are more biases than previously thought, so that an actual attack requires "only" observing a few millions of connections with the target secret always in the same place. While "a few millions" is rather low, it is still impractical, from the attacker's point of view, in a Web context. Thus, no cookie has been stolen in the wild through usage of RC4. Moreover, there are possible workarounds which are easier to implement in a browser.

Thus, there is no real incentive for a mass update of client TLS implementations. Indeed, browser vendors are accustomed to deal, on a weekly basis, with vulnerabilities which are much more devastating than that (typically entailing hostile hijack of the whole client system). A somewhat theoretical exploit of the cryptography in SSL is unlikely to be even noticed, let alone acted upon. What makes browser vendors move towards newer versions is the publicity which is made about these cryptographic attacks.

Moreover, and that's the important point, the protocol version which will be used for any given connection is constrained by what both client and server software support. Upgrading client support to TLS 1.2 will not change anything at all until most servers are upgraded, too. And, similarly, upgrading server support is not very useful until clients are upgraded. This is the classic Mexican stand-off, in which nobody moves, because it would require a massive simultaneous upgrade switch of several distinct vendors. For that matter, it is the same story as with IPv6 (which was scheduled for wide adoption in 2007).

In practice, several widely used browser rely on the SSL/TLS code of the underlying OS, so any mass upgrade will have to wait for the end-of-life of Windows XP (scheduled by Microsoft for next year).


VPS host shows plain text "root" account password upon reinstall of unmanaged VM I recently started using a VPS hosting service, that offers unmanaged VPS. It allows me to reinstall the VM at any point in time, choosing from a number of OS ISO files (doesn't have to be the same OS as before). You are probably already familiar with this kind of service.
When I first created the VM instance I had to enter a desired username and password and, optionally, a public key, for SSH access.
The thing that worries me, is that, upon reinstalling (through a web-based management environment), it shows me this password of the "root" account (not really root, but the main sudo account, that I had to create for the VPS instance), in plain text. Perhaps as a reminder for me, because they figure I may have forgotten it, because I am reinstalling the VPS. However, the more I think about it: why not just let me enter a completely new password?
Now, since they offer SSH access with public key access, as well, I figured, perhaps they have some nifty way to encrypt my password with that (or perhaps some secure master key of theirs), such that they can decrypt my password and only show me the password in my web-browser, when I want to reinstall the VM. But something tell me that that's probably wishful thinking, at best, or simply not at all the case, at worst.
What's more, is that they also offer shell access through web-based consoles (xterm and noVNC), presumably using the same public key I had to enter upon purchasing the VPS instance. Which made me frown a bit, as well.
What do you make of all this? Is this common practice and still reasonably secure, or are my intuitions correct in that it is considered bad practice and not possibly secure, at all?

If somebody wants to access your virtual server via SSH, they need the server's IP address and your password. However, if there is no password in place, they could immediately set a password and misuse your server. You assume that you will log in earlier than an attacker.
However, if your VPS provider already set a password, then the attacker also needs to guess it. There shouldn't be a problem if you change your root password.


How would you set up a ‘cold’ netbook for master-key signing, large Bitcoin transactions, etc? I've just ordered a cheap-o netbook on Amazon, with the intention of installing a Linux distro, and turning it into a permanently-offline high-security machine for sensitive tasks.

However, I'm no security professional, and I need some advice and tips, now that I'm finally undertaking this task. Amongst any general advice (or links to useful writeups!) you may have, I'm specifically curious about:

How do I install software, while keeping the machine ‘cold?’ For instance, in addition to the obviously-necessary updates and security patches for existing software, how would I go about securely installing new software if I found a new purpose to which I'd like to put the machine? (i.e. signing Bitcoin transactions, or something.)
What are the most security-conscious methods for transmitting ‘hot’ information to /from the machine? i.e. given recent concerns about USB-firmware exploits, how might you suggest I go about getting signed Bitcoin transactions to the 'net … or getting content I want to encrypt with my master-key to the cold machine?
Are there particular software choices you'd suggest? (i.e. which Linux distro, what software for managing keys, etceteras.)

(I intend to do a write-up of what I learn here, once I've worked through this process, to help others set up a relatively secure cold-storage for their Bitcoin and master signing keys.)

(Cross-posted here: http://redd.it/2k6jtw)

When you install the Linux OS, you have to assume that the software is the genuine one, free of backdoors. Linux distributions tend to use digital signature on packages; a digital signature does not guarantee absence of backdoor, but it prevents undetected alterations in transit: you know that the package you get is the one produced by the packager. Since you must make this basic assumption, the problem becomes one of networking: how do you get the packages into an offline system ?

There are several possibilities:

Burn a CD or DVD. On the plus side, most distributions can be obtained as a ready-to-burn ISO image, so you just have to make sure that you get the right one (download, compute the MD5 hash, compare with the value obtained from the source site over HTTPS), and you have a whole set of packages. On the minus side, a netbook won't have a CD/DVD reader, so you have to hook up a USB-driven reader.
Transfer the packages with some medium, e.g. an USB disk. As you note, this raises the possibility of a malicious firmware. An alternative is to use a CD/DVD writer, which is a lot more cumbersome, but arguably safer since a CD or DVD does not contain any firmware. In older times one would have used a magnetic support like Iomega Zip drives, but they have become rare nowadays, and are very expensive (in particular considering the size of individual disks: 100 MB... which is a lot when you think about it, but can be cramped with modern fat software).
Use the network. Of course, that's challenging on an offline machine, by definition. You may make a trade-off, with a machine which is mostly offline, but that you occasionally plug to the Internet. You would then want to use a direct ethernet cable, connected to another machine that will do some NAT and firewalling. That way, your security relies on the bridge machine not to be under hostile control at the time you connect.

One may note that for a truly offline machine, that never goes connected, then installing security fixes loses most of its relevance: a patch that prevents remote code execution in some server software is not needed if the said server software is never launched. You could simply run off a "base" set of packages, that you installed from an official ISO image initially.

Network attacks are definitely thwarted when there is no network at all, but you will want to consider other types of attacks, in particular wholesome theft of the device. This is a netbook; it is easy to carry and run away with. On the other hand, you will not keep it with you at all times (e.g. when you take a shower) so there will be periods when the device could be stolen. In that case, you want to make sure that the machine contains no intelligible secret when you are not using it. This points at encryption, unlocked with a master password that you keep in your head, and accept to type when you want to access the data.

You can do encryption on a per-file basis, in which case the tool of choice would be GnuPG (the opensource PGP implementation). To really use it safely, you have to use some care:

Don't configure swap space on your machine. You must run on physical RAM only. Most Linux distribution will want to setup some swap upon installation, so you may have to prevent it or deactivate it afterwards. Not using swap prevents potentially secret data elements from leaking to the physical medium underlying swap space: RAM contents disappear for good about one minute after poweroff.
Use a RAM-based filesystem. When GnuPG decrypts a file, it will write the cleartext as another file, and you don't want that file to hit a physical medium. Instead, you must make sure that you work in a filesystem backed by physical RAM only (type man mount, then search for tmpfs). This implies some care: encrypted files are stored on the disk, but when you want to decrypt them, you first copy them to a RAM-based filesystem and do the decryption/re-encryption there.
Make sure to select a strong password. That is, a random password, not a witty password. See this question for guidance.

You may have noticed that not using swap, and then carving up a chunk of physical RAM for a filesystem, implies higher RAM usage. If your cheap netbook has little RAM, then this may be a problem. A "raw" Linux can run in very little RAM (my first Linux could boot and run a graphical interface in as little as 8 MB of RAM without swapping, but it was in 1994). However, modern Linux distributions tend to eat up a lot of RAM (though not using a Web browser -- since the machine is offline -- will make your life much easier). In practice, I use Lubuntu; for the purposes you envision, you should be able to fit a comfortable Lubuntu with a 400 MB RAM-based filesystem in a netbook with 1 GB of RAM.

An alternative is full-disk encryption. If you use full-disk encryption, you can use swap and do not need a RAM-based filesystem. However, full-disk encryption will have to be done at installation time, and you don't get as much flexibility with regards to algorithms and tools.

Don't forget backup. You don't want to see your secrets stolen, but you don't want to lose them either, e.g. if the netbook, on day, refuses to boot. There again, you will need either encryption or physical protection (keep these CD in a safe), or both.

You will want to avoid forgetting your master password as well. For that, write it on a piece of paper, put the paper in a sealed envelope, and the envelope in a bank safe.


DNS Cache Poisoning as a Foil to SSL I recently learned a bit more about DNS cache poisoning, and my understanding of the basic way it works is by editing the DNS cache so that when the victim types in, say, www.google.com they get the attacker's IP instead of google's. So here is my question - is the following attack viable?

1) Take an address such as www.gmail.com, copy its HTML (or the HTML of its redirect) onto your machine, and change its IP in the DNS cache.

2) When a victim connects, they get routed to your machine. They probably get a certificate warning, but they ignore it because everyone ignores them... Anyway, you send them the HTML you already copied, but you edit it so that the username and password are sent to you (if necessary, I haven't parsed through the HTML of gmail's login)

3) Now with a bit of code, you can make it (I think) so that they establish an SSL connection with you instead of google. When they send their username and password to you you just edit the DNS cache back to the way it was and DeAuth them 20 times or so so they get a "connection problem." They log in again and everything is fine - no way for them to know that their password was stolen.

I think this attack is possible, except, perhaps, for establishing the SSL. I know how that works but wouldn't know how to program it -- but is it possible? Would you need to set up a server of your own or could your just route them to your local IP (I assume this would ring some bells somewhere). Thanks!

No, this attack is not feasible. Believe me, I've tried. Now when I say I've tried it, I was not writing a virus or something to steal passwords, I was writing software where the user was fully aware that they were using a custom DNS server which intentionally lied (based on their rules) in conjunction with a HTTP proxy. This is exactly what you describe, "poisoning" the DNS to basically lie to the software making the lookup and point it wherever you really want to the traffic to go. There are several issues that arise once you throw SSL into the mix.

1) Even if you have a custom DNS server or piece of software monitoring and modifying the DNS packets, there is no way inside this protocol to tell if you are dealing with requests for HTTP/HTTPS, or who knows what. So, you cannot tell what protocol the request is for. Even if you inspect the packet and look for the hostname, it will appear as "mail.google.com", not "https://mail.google.com", as an example.

2) In order to bypass the browser warnings, you need a few things. First, you need a trusted root certificate for your proxy or malicious server. Not gonna happen. Even if you manage to get the user to accept and install it (which windows basically makes sure to make the user feel like they're accepting an envelope with anthrax if they say yes), most browsers have their own trusted root authority certificate stores that they check against. So now you've gotta get the user to go out of their way to install your cert in whatever flavour of browser they're using as well.

3) Step two isn't enough. Now, if you've gotten that far, you have your malicious cert for your malicious server. Now you need to dynamically issue certs for every single host that a HTTPS connection is made or else guess what, the alarms still go off. These browser warnings aren't like the old days. Google chrome won't even let you proceed when it detects this going on, no matter how much the user wants to be careless with their own security.

Also, without doing any of this failed trickery discussed in 2 and 3, you get even less. All you can see on a socket level is the socket open from the app requesting the lookup, you see the host resolution happen over DNS, then a new TCP socket open attempting to connect to the host requesting a secure connection. The socket header doesn't contain anything except this basic request. As soon as the connection is made with the server, a handshake takes place and the HTTP connection becomes secured, at which time the hope of screwing with any of the data is lost.

The point is that the likelihood of this attack succeeding is basically non-existent. The user would have to ignore Windows' doomsday style warnings about certs, pass the Windows request for elevated administrator permissions (assuming you're using malicious software to directly poison the DNS cache or tell the system to use a malicious DNS server), then they'd have to ignore the giant red-screen, doomsday style warning in their browser (if their browser even allows it). It would be exceptionally difficult to pull of and would have minimal success even if you could.

All of this said, I really hope you're requesting this information for the sake of the good, not of actually attempting things like this. Tinkering around and learning these things can be fun and can aid in protecting users. Yes it would be perfectly ok to set up your own test network and hack it for fun and education, but doing and learning all this stuff to exploit people makes you a thug and a criminal and a disgrace to higher learning. I'm not saying you are this, I'm saying people who do that are. I hope you consider and weigh out these moral and philosophical questions in your adventure to obtain knowledge.

See also, for proof of browser protection from this issue.

Chrome SSL Warning: "You cannot proceed because the website operator has requested heightened security for this domain. "


A question about arpspoof command The arpspoof command will spoof default_router_ip's MAC address on all victims in the subnet

arpspoof -i <NIC>  <default_router_ip>

How does it fool the router about the MAC addresses of victim hosts in the subnet?

arpspoof -i <NIC> <default_router_ip>

Will tell all devices on the subnet of <NIC> that they should resolve <default_router_ip> to this machine instead.

Say your attacking box has eth0 IP 192.168.52.7 and the MAC address 00-14-22-01-23-45.

Say the router has IP 192.168.52.1 and the MAC address 00-14-22-01-02-03.

If you run arpspoof -i eth0 192.168.52.1 your system will constantly send out ARP replies stating 00-14-22-01-23-45 is the correct hardware address for 192.168.52.1.

Therefore when our victim, 192.168.52.100 asks for the MAC address of the default gateway 192.168.52.1, it gets 00-14-22-01-23-45 and routes all of its internet traffic to our attacking box instead.

Note that -t is optional, and is only used if you want to target one victim at a time (192.168.52.100 in our case). If not specified, all ARP caches on the subnet are attempted to be poisoned. If -t is specified, you can also specify -r so that traffic in both directions is captured. This then does not require two arpspoof commands to be issued.


DPI BitTorrent fingerprinting For limiting the usage of BitTorrent, I must identify BitTorrent traffic.

For handshaking, I am simply looking for "19" and "BitTorrent protocol" string.
If it is DHT I am looking for ping or id (d1:ad2:id20) commands.

All I am doing can be seen in the link

I generally catch BitTorrent at ~fifth packet.
But sometimes, my logic fails. I used Wireshark to understand when I can't tag BitTorrent traffic. I found out a UDP session with first three packets session like below picture:

I am looking uTP and DHT protocol specifications, but can't find anything like the traffic below. I am sure this session is BitTorrent, because in third packet, there is string "BitTorrent protocol".

It seems even Wireshark can't tag it as BitTorrent and shows UDP.
My question is, what is the rule for identifing the session below as BitTorrent protocol?

If a host has a single port that is connected to many remote hosts and this single port has a big port number (for example 50000 TCP/UDP port) and the same thing is true for destination ports, then most probably the mentioned host uses a BitTorrent client. This method can eliminate all p2p connections, not only BitTorrent.

In your case you may be interested in this topic:
Can BitTorrent Clients be Fingerprinted?


FIPS Compliance with HMACSHA1 vs HMACSHA256 / HMACSHA512 My organization has a group policy that is applied to servers enforcing FIPS compliance (Windows AD policy).

In .NET, HMACSHA1 is one of the encryption/hash algorithms that is FIPS compliant. I don't understand how HMACSHA256 or HMACSHA512 is not also in this FIPS compliance list. Is HMACSHA1 somehow a stronger hash than HMACSHA512? How could this be?

FIPS compliance list for .NET:
http://blog.aggregatedintelligence.com/2007/10/fips-validated-cryptographic-algorithms.html

"FIPS compliance" is about more than the algorithm. It is about implementations. Being awarded the "compliant" badge is a long, complex and very expensive process; its conceptual meaning is that there are some strong reasons to believe that the implementation is correct and secure and fulfils a number of security properties. Since we don't really know how to prove that software is correct in all generality, most of FIPS compliance is done through audits and analysis of development process. This is rather thorough; this includes, for instance, making sure that during development, source code versioning was used, with proper attribution of each line of code to a properly identified developer, for whom some background checks were performed.

In practice, getting compliance implies producing a lot of paperwork (many thousands of pages) and even more auditing, for a cost that easily goes to $50000 or more, and takes up months. Costs grow up quickly with the scope. Apparently, in 2007 (from your link), Microsoft went through the whole ordeal for HMAC/SHA-1 but not for HMAC/SHA-256 or HMAC/SHA-512, which is why the former is "FIPS validated" but not the latter.

This may be related to the fact that back in that time, .NET could use the SHA-1 implementation from the Win32 layer (CryptoAPI), in native code, while SHA-256 and SHA-512 were "managed" code; doing FIPS compliance for HMAC/SHA-256 with the managed implementation (SHA256Managed) would have thrown the CLR runtime, including the JIT compiler, within the scope of the auditing, and price would have probably skyrocketed. A native implementation of SHA-256 was added in .NET 3.5 (SHA256Cng) but it was released only at the end of 2007, too late for the compliance shown in the list you link to.


SQL Injection : How to begin when the id parameter value is not numeric I am learning SQL injection currently and I feel I am quite comfortable doing Basic SQL injection. I am learning it by solving online challenges and so far I have only come across situations where the 'id' parameter is numeric. eg: http://abc.tld/xyz?id=1

Now I have come across a situation where the id parameter value is a mixture of random characters and numbers.I tried generating an error using all the possible ways, from single quote to true and false queries to no success. I also thought it could be an encoded from something, hence tried to decode it as well using online converters.
I don't need help solving the challenge, I need to know the various ways in which I can approach a URL like http://abc.tld/xyz?id=DETODHS35B5H56H.

The type of argument there should play no role in SQL injection other then how the SQL query is formed in the first place.

SQL injection abuses a SQL query being created from the parameter as a string. Web server treats the whole URL as a string and parses all the parameters as string as well. So even when the id is numeric, such as 1, it is treated by a web server as string and the code then inserts it as a string. This allows you to insert special characters, which would not be possible if only numbers were allowed.

However, there may be difference in the SQL query. When using string in a SQL query, the string has to be enclosed in single quotes '. Numbers can, but don't have to be.
Number: SELECT * FROM Test WHERE id = $NUMBER;
String: SELECT * FROM Test WHERE id = '$TEXT';

When you have a string enclosed in quotes, you have to close the quotes first. So for example you would send A'; DROP TABLES *;-- which would give you:
SELECT * FROM Test WHERE id = 'A'; DROP TABLES *; --'.
You can see the ' finishing the first ' so that your DROP TABLES *; command is treated as a command and not as text. The -- is used for comments in SQL and here we use it to get rid of the closing '. Otherwise, it would cause a malformed SQL query.

Please note that numbers CAN also use quotes in a query, so using this escaping method may be useful to try even if the site only uses numbers in the parameter. Also, depending on the SQL engine, other types of quotes then single quotes, such as double quotes may be usable, which would change how you have to escape them.


I can't figure out the abnormal behaviour from this Wireshark capture file The capture file if needed

There is supposed to be abnormal behaviour here, and I see that there is. But I can't figure out what it is.

There is no response from the ICMP requests. Furthermore some packets have the warning:

  [Expert Info (Warning/Protocol): Source MAC must not be a group
  address: IEEE 802.3-2002, Section 3.2.3(b)]
      [Source MAC must not be a group address: IEEE 802.3-2002, Section 3.2.3(b)]
      [Severity level: Warning]
      [Group: Protocol]

I was thinking it might be a Ping flood attack, but shouldn't there also be a reply/response from the destination address for this to be the case? The host might already be overwhelmed thus making it unable to respond to the ICMP requests, but that isn't shown in the capture file.

The packet length is 60, so it doesn't match it being a Ping of Death attack either.

Any help is greatly appreciated!

There is two things suspicious on the pcap file:
1. as Steffen mention the sequence number looks like is from the same machine, probably the generation of the packets is on a for loop
2. In general, the ICMP requests contains the alphabet in order to reply with the same, and in the pcap file is all set to zero.

Could be a a botnet behavior or somebody playing with packets on the internet and his program is not ready to work as expected.


Security of my homebrew hash algorithm I am developing a 16 chars long hash algorithm. I have a second algorithm that generates random 1024 char strings. This algorithm loops and detects if there's a collision between the newly generated hash and any previous one.

How many iterations with no collision do I need before I can claim that my hash algorithm is "almost secure"?

How many iterations with no collision do I need before I can claim that my hash algorithm is "almost secure"?

Never. You can't claim your hash algorithm is secure. It needs to be carefully audited by talented cryptographers / mathematicians who know exactly what they're doing.

You can't expect to have enough computing power / money to bruteforce it long enough, especially if you're alone. It took Google more than a year and more than $1 million to find that famous SHA-1 collision. Do you think you have enough time / money?

Also, bruteforcing alone isn't the best way to crack a hash function. The function can have major flaws which could be very hard to find via bruteforce. That's why you need talented people to audit the algorithm.

Unless all that work has been done, you should really use standard hash functions which are considered secure nowadays.


Is it safe to use a ECDSA public key as a password seed for GCM/AES? Two peers already exchanged their ECDSA (curve secp256k1) public keys using a secure channel.

They want to establish an authenticated encrypted channel between them. They will use CCM mode and with the AES block cypher (as implemented in the SJCL crypto library).

Is it safe for them to use as a key for CCM the output of PBKDF2(iter=1000) of the other peer's pubkey? Is there a better solution without exchanging more data off channel?

(public keys are 33 bytes long).

EDITED:
These pubkeys are not public, only shared between the two peers.

This seems... confused. PBKDF2 is a Password-Based Key Derivation Function. It is used to process a password, i.e. a secret piece of data that both parties share.

In your case, they don't share any secret piece of data. They know each other's public keys, which are public, so they are known to everybody. Putting them in PBKDF2 won't turn them secret.


Split a JWT between payload and signature Context: I'm looking at storage solutions for JWT tokens on a single page application.

Storing the JWT in the local storage is unsafe and prone to XSS attacks.
Storing the JWT in a secure / HTTP only cookie is safer, but prone to CSRF attacks.

I'm studying the following scenario:
Upon authentication, a refresh token is stored in an http only secure cookie. It can only be used to get an access token.
Upon authorisation, the backend responds with a JWT access token. The header and payload part of the JWT are inside the response body. The token signature is not sent and is set in an http only secure cookie (same-site strict if possible, but let's assume it's not the case). The header + payload is stored in memory.
The JWT contains the following claims

iat, nbf, exp (guessable IMO)
claims relative to the user identity and permissions (guessable if the user identity is known)
jti, containing a cryptographically secure random number (in my case generated with python secrets)

When making requests, the header + payload is sent via XHR/fetch by the SPA in an Authorisation header. The signature is sent along with the cookies. The backend concatenates both and verify the signature.

Is this mechanism safe against CSRF attacks ? Does the jti claims makes the Authorisation token + signature cookie a valid CSRF mitigation technique ?
Is this mechanism indeed safer against XSS attacks than storing the JWT inside the local storage ? (Could an attack using XSS also easily steal the signature, like with a TRACE exploit).

Note: I've read this question which is similar, but overly broad so I'm posting this to get a more precise answer.

Is this mechanism safe against CSRF attacks?

This method of splitting a JWT and storing the signature in the cookie and the rest of the token in Browser Storage does not provide any additional protection against CSRF attacks than if the entire JWT was stored in Local or Session Storage. Yes, it will mitigate CSRF attacks, but you don't need to add the unnecessary overhead of splitting and concatenating JWTs on the server. Storing JWTs in Local Storage and accepting them only in Authorization headers is enough to protect your application from CSRF attacks.

Is this mechanism indeed safer against XSS attacks than storing the JWT inside the local storage? (Could an attack using XSS also easily steal the signature, like with a TRACE exploit)

If your focus is solely on an attacker being able to steal JWTs, this approach is safe unless, as you rightly mentioned, TRACE is enabled on the server.
However, this does not make your application safer from XSS attacks. For example, if I am able to execute arbitrary Javascript on your application, I can fetch the JWT header+payload from Local Storage and just send an XHR to a sensitive endpoint keeping withCredentials set to True. This endpoint might be designed changed the account email address, for example. That straightaway leads to an account takeover. No need to steal cookies or JWTs.
Summing up:
This approach does provide some protection against session tokens by separating the signature from rest of the token. However, when it comes to XSS, stealing session tokens is not the only risk that you should be looking at.


In practice, is it safe to set Strict-Transport-Security header on non-SSL requests? Section 7.2 of RFC 6797 states:

  An HSTS Host MUST NOT include the STS header field in HTTP responses
  conveyed over non-secure transport.

In practice, I have a lot of hosts that are behind an Amazon load balancer that where requests from ports 443 and 80 are forwarded to the same Nginx configuration.  It would be considerably simpler to always send the Strict-Transport-Security header, regardless of the incoming protocol used.

I don't care if the UA ignores the header on insecure requests. I'd just to like to confirm if this RFC violation causes a problem in practice.

Insecure requests are already redirected to secure versions by the server, where the UA would then receive a valid Secure-Transport-Security header in their response.

If the requirement is MUST NOT, then in theory some browser can display an error instead of a page that has this header when fetched via plain HTTP.  It is highly unlikely though.

(Update: this unlikely behaviour is actually forbidden by the same RFC.)

Clearly the point is that over HTTP nothing can be trusted to originate from the original server, so if any browser would interpret it when seen with HTTP, then this header could be (ab)used to force the server appear offline for an extended time without the consent of the server operator, with sufficient capabilities to control the network path.

New UA/client software authors still could make a mistake of interpreting this header, and it can be a good protection against this if you make it a requirement to not ever issue HSTS via HTTP - so that it can be flagged and reported as an error by any validator.

Though I did not test this, with nginx, it's not very complicated to say:

if ($scheme = https) {
    add_header Strict-Transport-Security max-age=18000000;
}

The only issue I can foresee is when you have a limited SSL offloading frontend proxy and you can't easily tell whether the request is SSL or not.  In that case you actually must issue HSTS via HTTP, assuming your CDN/proxy does not have a way to configure HSTS.