SSL encryption work only in content? Can SSL encrypt the relative path I would like to visit in a site?

If I would like to make a login system with GET instead of POST, can SSL encrypt the part "?username=user1&password=pass1".

SSL does protect the actual files being accessed.  It actually occurs at the IP level, but the main part of the URL leaks via DNS.  This is why you can only have one SSL cert per IP address, because until the connection is established, the server has no idea what is being requested unless SNI is used (which still just provides host name during the connection being established).


Questions on true anonymity I am going to use Tails to connect to Tor through VPN which has AES-256 data encryption, SHA-256 data authentication and RSA-4096 handshake encryption on my Mac on my school's WiFi (as public as I can get).

Is there anything I can do to make it more anonymous and make it so that no one can trace me back? Maybe I could have a program that bounces my IP address across servers, etc.

Edit: my school does not required log in, it does not have any password either. I have 4 other Facebook account none of which uses my real name.

Even if Tails offers  anonymity and coming with default built-in encryption suites for different purposes, your anonymity is already compromised since as in all schools/universities we find the same policy: to use their WiFi they need to be sure you are either a student, a teacher or an authorized person to access their Wifi.

Also you must remember that  Tor browser as well as the whole Tails operating system privacy-protecting flaws show that no anonymity system is fail-safe: you need to keep yourself Tails/Tor up-to-date to security issues as mentioned in this recent May 2015 report where it is stated that when it comes to anonimity:

  there is no magic or perfect solution to such a complex problem.

Some vulnerabilities listed from that report:

Tor exit nodes can eavesdrop on communications
Tails makes it clear that you are using Tor and probably Tails
Man-in-the-middle attacks
Confirmation attacks


Is it a good idea to use non-Latin Unicode characters in a password? I've heard many suggestions as to what makes a good password (hard to guess, not a dictionary word or permutation thereof, at least a certain length, etc.) so that it cannot be cracked in a realistic amount of time. However, from what I understand, password cracking techniques and software will try to use Latin characters, digits, and special characters that you would typically find on a US keyboard. Therefore, would it be a good idea to include some non-Latin characters in a password?

For example, "passw密码rd".

Probably not - you would find many compatibility problems depending on the supported character sets of devices that you may need to enter your password from.

There are two ways of making sure you have a strong password:

Use a source of entropy that the attacker isn't aware of.
Use enough entropy so that brute force is infeasible.

The approach your proposed method takes is the former. There are usually fewer disadvantages of the latter approach. If you use a password with at least 128 bits of entropy it cannot be guessed in a reasonable amount of time. That is on average - if the attacker is very lucky they might guess it first time - but the same is true with all passwords.

So to get 128 bits of entropy you either need a password with at least 20 completely random characters (using both case letters, numbers plus ASCII symbols) or you need 10 randomly selected dicewords.

So in my opinion this is already a solved problem. Use a secure password generator to create a random 20 character password if you don't need to remember it, or use Diceware if you do.


How do anti-exploit programs work? There are plenty of answers available which detail how antivirus and anti-malware programs work, including details on signatures, heuristics, sandboxing, etc. However, there seem to be relatively few resources on how anti-exploit programs (such as EMET, MBAE and HitmanPro.Alert) actually detect and prevent exploits.

The actions that actually occur during an exploit seem to be almost impossible to detect without attaching a debugger to the process, which would appear to have unacceptable performance impacts.

What are the different methods used by anti-exploit programs to detect and mitigate exploit attempts?

I'll answer this based on my experience with the CBMC compiler.  I never used HitmanPro, malwarebytes anti-exploit or Microsoft's EMET but I do not see any reason why they would do things completely differently from CBMC.

Known exploit protection

If we look at the malwarebytes anti-exploit video (kindly researched by OP), we see that MBAE could find an exploit by identifying a downloaded malicious file.  That is exactly how a modern anti-virus program works: it checks the signature of a known malware (or "exploit payload" if you want to call it that way) and stops its execution if it matches.

In that specific case we can argue that Anti-Exploit is simply a re-branded name for an Anti-Virus program.  In theory you can argue that AV (Anti-Virus) only checks signature of files, whilst AE (Anti-Exploit) checks the payload (e.g. whiled downloading a file)  You can also argue that AEs searches for CVEs whilst AVs search for malware signatures.  But all modern AVs perform all that: they are updated when CVEs come out, they check signatures of network traffic (downloaded files) and they do that in real-time.  So I'll argue that, from that video, we can conclude that AEs are simply AVs rebranded.

Yet, there is more: AEs promise to be able to find zero-day exploits.  And that would be different from AVs.

Zero-day exploits

You can't find a zero-day exploit in a program without running the program.  But running a dodgy program is unwise.  This is because, if there is an exploitable point in the runtime environment, running a program may exploit exactly that breach.  Sandboxing is an option, but sandboxes often have breaches of their won.  So, how can we execute a program without executing it?  Symbolic execution to the rescue.

As I said at the beginning of the answer I'll use CBMC, a tool I needed at some point in the past.  It performs symbolic execution, but it is a research tool.  And no one really argues that symbolic execution can find all possible problems a program may have.

CBMC is a C compiler (and has a commercial version for VHDL too) that does not compile a program into machine code.  Instead it compiles the program into a language called GOTO, which is a simplified symbolic representation of the program.  Then a GOTO processor (part of CBMC) is used to run the symbolic representation of the program.

A symbolic representation is much easier to reason about, and the program can be run assuming a wide range of inputs.  For example, one of the things that CBMC/GOTO catches well in C programs are buffer overflows.

Now, CBMC works on C and VHDL programs, but the same can be done with assembly.  Although it would not be as accurate as constructing a symbolic representation from the source code (since disassembly is not perfect), it would allow to execute the symbolic representation of the program and check for coding mistakes.

Buffer overflows are the easiest things that one can think that can be found in the assembly as well, but other possibilities may include unchecked input (input is tracked in a symbolic representation, at least in CBMC) or opening network sockets (since it is a known syscall).

Disclaimer: I do not know how an AE is actually built, but if I had to build something that can find a zero-day exploit automatically symbolic execution would be the path I'd try.  Symbolic execution does not come without issues (known to the open research community, some non-disclosed sources may have found solutions to some of them):

SE does not find all problems, e.g. interaction between different configurations is often not found.
SE is rather slow.
Intel or ARM (or any other) disassebmly is never perfect, and disassembly problems reflect into SE results.


Alternative to ICANN? What are major DNS services offered that aren't state-controlled. Better yet, why can't we take Bitcoin's model and create a truly decentralized system with P2P DNS?

I see potential reasons behind P2P DNS:

Logistical nightmare
Endless domain registration
Much like shift from ipv4 to ipv6

You can do it if you want to. Go ahead. No? Why haven't you switched yet?

Yep, there's the problem. Nobody else switched. If you change the rules, you're effectively creating a different Internet. One that isn't entirely compatible with the Internet we all have, which means nobody is on it but you.

This Internet, the one we're using right now, works well enough. There's stuff we don't like, but altogether it works well enough that nobody wants to start over.

If you want to change some rule, like DNS or routing or some other core component, chances are there's a few people on the fringes of society who will play along. So set up your Alternate DNS Root and talk to them. Five dollars says I know what they'll want to talk about.


How does the TPM provide security for the cloud? The primary scope of TPM is to assure the integrity of a platform. In
  this context, "integrity" means "behave as intended". ~Wiki

I'm learning more about how the TPM performs integrity covering aspects as root of trust, chain of trust, PCRs measurements, remote attestation.

On the other hand, a cloud provider needs to enforce strict security policies, requiring additional trust in the clients. To improve the mutual trust between consumer and cloud provider, so how is the TPM related & applies to security in the cloud?

The most useful case for TPM-backed security in cloud computing is providing greater assurance to a tenant that the cloud provider is running the software they expect. Because the cloud provider controls the hardware the software is running on they (or someone who hacks their infrastructure) are in a privileged position and could insert rootkits or otherwise compromise the expected security properties of the software the tenant asks them to run. However, software running on machines equipped with TPMs can attest to the state of their platform, allowing the tenant to remotely verify that the software is in a desired state (i.e. only the expected code has been run). A TPM can also be used to restrict the usage of certain keys or credentials so the cloud provider cannot copy them or use them outside of the context of running the tenant's workload.

It's important to realize, however, that TPMs do not provide physical security. They are typically tamper-proof themselves, but even if you trust that the TPM can protect its root keys and is operating correctly its only awareness of the system's state is through by a series of measurements provided by other hardware components and software processes. Barring serious CPU/chipset/firmware flaws, this sequence of measurements cannot be faked by malicious software -- but it can be faked by anyone with physical access to the TPM chip and a soldering iron. This means that a tenant always has to trust the cloud provider to some extent; still, TPMs can provide effective defense against hackers who might compromise a cloud provider's infrastructure, which is usually what people are more concerned about.


Determining the point of compromise on an infected web server? Recently a friend of mine has had his web server compromised - all PHP files were injected with malicious code, in particular one that looks to be called "GetMama". If I look this up, it seems that most people say it's a piece of malware which targets WordPress installations (and I can't find anything to the contrary). His site however doesn't have any WordPress installations on it. The server is shared hosting courtesy of BlueHost, with SSH/FTP access. If GetMama is meant to be an automated virus, I'd love to know how it compromised the site without any WordPress installations. After cleaning GetMama up from all infected files with some regex magic, a few days later it would be back. I searched the site for any sign of compromise but I wasn't able to find any. The access logs only seem to date back 24 hours or less (I'm not sure if this is BlueHost policy or logs getting wiped). Other symptoms included a manual compromise of the forum administrator's account, injecting malicious code into vBulletin's templates. The site owner changed the passwords, and there were no further forum compromises. After thinking the site was finally clean for a while, malicious JS was sent to users by a 301 redirect in a .htaccess file.

Basically, I'd appreciate knowing how you guys would deal with a situation like this. I can't work out how to find the point of compromise. For example, that .htaccess file popped up in the last few days, but there's no recorded data on how - only when. Same with the malicious PHP code injection, I don't see any data on what modified those files. We changed passwords, but even so, SSH doesn't report any unauthorised users logged in in the past few months (at least). What methods could I use to analyse future infections and locate their point of compromise (bearing in mind I'm on shared hosting without root privileges to work with)?

Ah, the joys of shared hosting. You can be 99.9% sure that in this incident, another shared hosting service on the same server, which is running WordPress, was hacked by this automated script. This would answer the first part of your question.

The underlying question is 'how did somebody else's account being compromised affect MY account?'. If this GetMama auto-attack didn't run some kind of PHP exec() command to exploit a Linux vulnerability then there's some kind of permissions issue going on that BlueHost need to address. These things can get in to other accounts by many ways, including through shared database servers with incorrect user permissions specified.

(disclaimer - this is a general answer, I didn't google 'GetMama' at all)

All in all it's a prime example of the importance of keeping your webapps up to date. Especially popular packages such as WordPress or vBulletin as their wide-spread use makes them obvious targets. Keeping things up to date helps to keep your site safer and also helps you be a good neighbour by reducing the potential of trouble for other users. Same goes for people running the servers.

Best way to protect against this is to not use shared hosting. These days a low-spec VPS can be found for the price of decent shared hosting (~$30/m).


iOS 8 encryption vs Android Lollipop encryption iOS 8 includes encryption that is enabled by default, whereas in Android it is optional.

Do both operating systems decrypt everything on boot and then the PIN is used to unlock it until it is turned off? Turning off wipes the decrypted files from volatile memory. Then when the user boots their PIN decrypts them all again. Is this true?

If so, does this mean if an encrypted device is taken when it is powered on then the pin could be bypassed (with difficulty) and the files could be accessed in a decrypted format?

This is a common misconception. The purpose of full disk encryption is to protect against offline attacks, where the storage has been connected to another computer that the attacker controls.

(For a phone, this "other" computer is typically still the phone's hardware, but booted into and running a custom OS, just because this is easier to do than to physically extract the storage from the phone. Works out the same.)

When the disk is connected to the computer it is meant to be then it is the operating system's job to protect the files, FDE does nothing.


Whatsapp web security If I use WhatsApp Web on a computer at work that is connected through a proxy, is there a possibility that they will intercept my messages?

I know that, thanks to the proxy, they can see the pages that I visit, but they could also spy on WhatsApp conversations?

No.  Whatsapp, Signal, and other secure messaging systems use end-to-end encryption.  You can read more about the underlying algorithm here:
 https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm.

That being said, if you are using a work computer which your employer controls, your employer may be able to read your messages on your local machine before your messages are sent and encrypted/after they are received and decrypted.


How much added security do I really get with a longer key size? Imagine I have a cipher which supports keys of 128, 192 or 256 bits. Suppose that there are no vulnerabilities in the cipher regardless of key length. I'm going to use it to encrypt something, and I'll use a password or passphrase.

If I use the same password, does it really matter what the key size is? Since it seems like bruteforcing all 2128 possible keys is not feasible in the foreseeable future, am I correct to assume the strength of the encryption is based almost solely on the password?

Assuming the key derivation function takes the same amount of time to generate a key of any size, doesn't this mean an attack on the password will take the same amount of time regardless of key size? Thus, isn't the strength of the encryption much more a function of the strength of the password than the key size?

If that holds up, what do I gain with a 256-bit or 192-bit key instead of a 128-bit key?

Once you've reached the "cannot break it" zone, increasing the key size does not change security: you cannot be more secure than that. A 128-bit key is already far into the "cannot break it" zone. Larger keys are for marketing people who need to impress gullible buyers, and for military people who must, by statute, make extensive displays of their collective manhood.

(The best marketing managers try to rationalize larger key sizes by talking about quantum computers.)

If you derive a key from a password, and extending the key from 128 to 256 bits changes anything to your security, then you are doing it very wrong.


What are the performance and security tradeoffs when selecting "ECC" or "Subgroup" in a U-Prove token? In one of the U-Prove documents, I remember reading something that compared Subgroups versus ECC and it went something like this (paraphrased):

Subgroups

Requires a bigger key to achieve equivalent ECC security

Unclear: What aspect of the UProve protocol does this affect?
When compared to ECC, I'm not sure if this growth is linear with Attribute count in a particular certificate, Disclosed count, or is a static growth added to UPTokens or Proof ?

Described as less complex than ECC, and is "new" in the 1.1 release of the SDK.

Unclear: are subgroups vetted, well understood and 'safe'?   I don't want to implement a solution that hasn't achieved a consensus of trust.  I believe the focus here is on the Discreet Logarithm assumption.  Better question: Which is "safer"?

Run faster than ECC

Unclear: Is it faster for Provisioning, Proving or both?
This is important since an implementation may need many one-use UProve tokens, or one that can be multiple-show.  The answer to this (and the degree it affects each) will affect architecture decisions.
Unclear: Which protocol can be optimized for parallel computing?
In my tests, only a single CPU ever had a load on it,.. often reaching 100%.  I suspect the C# implementation wasn't optimized for parallelisation in either implementation (ECC/Subgroup)

Question

Can someone clarify any of the aspects listed above as unclear?  I've been researching the Microsoft, and Credentia website for as much information as I can find..

For your reference, the aspect of the API that controls the creation of the IdP as described above is here:  (C# / Java)

    private static IssuerKeyAndParameters CreateIssuer(string UIDP, int numberOfAttributes, GroupType groupType, bool supportDevice, string specification)
    {
       // specify the group type: subgroup (default) or ECC
        isp.GroupConstruction = groupType;

        IssuerSetupParameters isp = new IssuerSetupParameters();
        // pick a unique identifier for the issuer params
        isp.UidP = (UIDP == null ? null : encoding.GetBytes(UIDP));
        // set the number of attributes in the U-Prove tokens
        isp.NumberOfAttributes = numberOfAttributes; // alternatively do this:  isp.E = IssuerSetupParameters.GetDefaultEValues(numberOfAttributes);

        isp.UseRecommendedParameterSet = true;

        // an application profile would define the format of the specification field,
        // we use a dummy value in this sample
        isp.S = (specification == null ? null : encoding.GetBytes(specification));

        return isp.Generate(supportDevice);
    }

Update
Here are some performance tests that clearly show how Subgroups greatly outperform ECC based verification

Group Type:Subgroup
                               Attribute Count: 5
                     Time to create 100 Tokens: 00:00:35.7045391
 Time to validate 100 presentations of 1 token: 00:01:44.2874433

Group Type:ECC
                               Attribute Count: 5
                     Time to create 100 Tokens: 00:02:52.5378040
 Time to validate 100 presentations of 1 token: 00:08:22.3521344

U-Prove is a technology which is, roughly, a mix of digital certificates and blind signatures. The Prover has a few "attributes" that the Issuer (i.e. the Certification Authority, more or less) asserts to be true. However, when dealing with any given Verifier, the Prover wants to be able to choose what he shows: namely, he wants to show only some of the attributes. Moreover, when the Prover deals with several distinct Verifiers, the Prover does not wish the Verifiers to be able to correlate their inputs and notice that the same Prover was involved in both cases.

In the specification, the cryptographic algorithms which achieve that are described. Namely, there is a finite group in which all participants play. That group is either a subgroup of the integers modulo a prime p, or an elliptic curve. The group has a size q (in the "subgroup" case, q is necessarily a divider of p-1). Each group element can be represented as a sequence of bytes. The group must be such that discrete logarithm is not feasible.

To give some figures: suppose that we want "112-bit security", i.e. something quite strong by today's and tomorrow's standards. This is a level of resistance which cannot be broken unless the attackers musters enough computing capabilities to perform at least 2112 elementary operations, a figure which is way too high to be economically feasible with today's technology. To get this level of security, the group size will have to be at least 224-bit long (q must be no less than 2223). For the elliptic curve, it will be sufficient to have a "224-bit curve" whose elements can be encoded over a sequence of 225 bits (or 224 bits in some cases, depending on the underlying protocol). On the other hand, when working modulo a prime p, there are known shortcuts for discrete logarithm, so we need a much bigger p, up to about 2048 bits (see this site for a lot of data on the subject). An integer modulo a 2048-bit integer p can be represented as a sequence of 2048 bits.

In that sense, when using the "subgroup" model, group elements used in U-Prove tokens are about 9 times longer than what they would have been if the "elliptic curve" model had been used, for the same level of security. Note, though, that the "9" figure depends on the security level (it is not linear).

A U-Prove token itself contains a number of fields, two of which (the public key h, and a part of the signature σ'z) are group elements. Therefore, for the 112-bit security level, a U-Prove token using a "subgroup" ought to be about 455 bytes longer than a U-Prove token of equivalent security but relying on an elliptic curve. Mind the "ought to": this figure is theoretical; I haven't tried. Encoding peculiarities may change that a bit. Also, a U-Prove token includes other fields which may dwarf this difference, to the point of making it irrelevant. This really depends on the usage context.

As for performance, the text you quote is weird, because, usually, elliptic curves are faster (because they work in a much smaller field). In practical situations involving computers or smartphone, computing costs are usually negligible with regards to I/O (network latency and so on), but when smartcards are involved, the difference can be important. If a given implementation of U-Prove is faster with 2048-bit subgroups than with 224-bit elliptic curves, then that implementation is quite sloppy (as @CodesInChaos says in his comments).

On security: Current state of affairs, with regards to the relative resistance of prime subgroups and elliptic curves, has not changed much in the last 20 years. Best known algorithm for discrete logarithms modulo a big prime p is still a variant of the General Number Field Sieve, and there is no known shortcut for discrete logarithms in elliptic curves.

Although computations in the "subgroup" case are slower and need bigger values than elliptic curves, they are also noticeably simpler to implement, in particular when it comes to thwarting side-channel attacks (e.g. timing attacks). Implementing robust cryptographic primitives is hard; don't do it unless you really must. But if you have to do it yourself, then you will prefer the "subgroup" case.


Encrypt data going through an encrypted connection If data are passing through a SSL-encrypted connection, is it required to re-encrypt these data? In other words, is it mandatory/useful/worth it to AES/RSA (for example) encrypt data that will be re-encrypted with SSL?

SSL uses a cryptographic system that uses two keys to encrypt data so you do not need to enforce encryption by AES and so on. SSL auhenticate Web servers, and encrypts communications between Web browsers and Web servers.. Websites (bank websites, for example) rely on SSL even to retrieve very sensitive data of their users because this protocole ensures by itself data integrity.

SSL uses assymetric encryption for authentication (between the server and client). After authentication is established, they start to communicate using symetric encryption because it is faster.

From the schema above, you can see data is transferred between the server and the client after authentication is made. Encryption of this data is made after (and thanks to) exchanging the cipher key (symetric encryption)


Email security between Outlook and Exchange 365 From what I've understood by reading message headers and settings in Outlook, mails sent between Outlook on my PC and the Exchange cloud service are encrypted with TLS 1.2. Messages moving within the cloud between domains are also of course secured in the same way.

Is this more or less secure than transferring files to a server through an HTTPS connection? And how about when, let's say, mails go from Exchange to Google's cloud. Do they also transfer over TLS?

You cannot guarantee that emails sent outside of the control of your email provider are sent encrypted. That's up to the receiving email server.

So, no, there is zero trust that anything you send will be encrypted end-to-end (that's why we have all these end-to-end encrypted IM platforms).

Transfering files to a server over TLS offers far more control and security functions with fewer complications (and fewer parties involved). This should be considered the more secure option than emailing files.


What websites can be protected by a particular SSL certificate? What websites (URLs) can be protected by one SSL certificate?

For example, www.security.hsbc.co.uk has a SSL certificate. Can this certificate be used to protect other websites (URLs)? Something that branches off from this one maybe?

If you view the certificate in your web browser, you should be able to find the certificate subject alternative name value for the certificate.  This will show a list of all of the sites that can be secured using this certificate, in addition to the site shown in the common name for the certificate.  You may see wildcard values used in some of the names, such as *.hsbc.co.uk or *.security.hsbc.co.uk.

As an example, if you look at the certificate protecting this page, you'll see that Stack Exchange uses one certificate for all their sites:

Firefox :

Chrome :

The site we're currently on, https://security.stackexchange.com is covered by the wildcard SAN *.stackexchange.com.

Bear in mind that in order for any site listed in these fields to use this certificate, the site would need the private key that corresponds to the public key in the certificate.

These conditions must be met in order for your browser to make a SSL/TLS connection to the site, without warnings.


JavaScript written only with brackets? I once saw JavaScript code which was only written as multiple brackets (). Does anybody remember this kind of code? There was also an online converter to convert "normal" JS into this style of code. I want to show it while a presentation as an example of state of the art XSS. Or what are other really surprising XSS examples?

Found it

http://sla.ckers.org/forum/read.php?24,33349
http://security.bleurgh.net/javascript-without-letters-or-numbers
http://sla.ckers.org/forum/read.php?24,28687

Converter to convert normal JS into brackets only JS:

http://utf-8.jp/public/jjencode.html


File types and ways that can infect Android devices with malware From what sources can an Android device be infected with malware?
What various file types, executable or non executable, can infect an Android device with malware?

The key thing to remember about malware on Android is that you have to actually install the malicious app. Malware writers will use increasingly clever techniques to try and trick you into doing just that.

So, can an android app on Google Play be fake or malicious?

Yes, it might be.

What can an Android malware/virus do?

The vast majority of malware on Android is focused on stealing your information, which is obviously a major concern. Perhaps the worst case scenario at the moment is malware that sends SMS messages to premium rate numbers.

There are apps that clone legitimate apps to fool you into downloading them and apps that are malware free when you first install them, but download malware through the update system.

The most common Android malicious apps will do at least one of the following:

Collect and send GPS coordinates, contact lists, e-mail addresses
etc. to third parties
Send SMSs to premium-rate numbers
Subscribe infected phones to premium services
Record phone conversations and send them to attackers
Etc.

If they have the permission they will use it! (ex: If you give access to your camera ... they can use your camera)

Is there anything more dangerous then that?

Yes. Your phone is a mini computer and you install things on it. If one of your installed application has vulnerabilities (ex: Remote Code Execution) maybe a hacker can hack your device if it is on the same network or it can send a specific targeted payload.


openssl s_server without encryption Is it possible to use openSSL without encryption nor certificate?
To test something, I want to connect without any PSK/certificate.
Maybe just DH. I tried this:

server:

openssl s_server -cipher ECDHE-RSA-NULL-SHA -accept 44330 -www -nocert

client:

openssl s_client -connect 10.10.1.87:44330 -cipher ECDHE-RSA-NULL-SHA

Output:

CONNECTED(00000003)
4561129068:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.11.1/libressl-2.8/ssl/ssl_pkt.c:1200:SSL alert number 40
4561129068:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.11.1/libressl-2.8/ssl/ssl_pkt.c:585:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Start Time: 1582716971
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

So the handshake failed (SSL alert number 40).
What am I missing here (if it's possible)?

I changed the ciper to AECDH-NULL-SHA and now it's connecting.


Creating a word list Is there anything out there that can create a word list with the following parameters?

Password contains [string_1] = aaaaaaaaaaaaa
Password also contains [string_2] = bbbbbbbb
[string_1] comes before [string_2], i.e [string_1][string_2]
There is an unknown string between them and an unknown string at the end. ie.
[string_1][unk_1][string_2][unk_2]
[unk_1] and [unk_2] have: min length = 1 , max length = 3 , only contain             characters [123!]

Altogether there isn't a massive amount of combinations compared to how long the password is. Is there anything I could use as my coding ability is slightly lacking.

Examples of password:

aaaaaaaaaaaaa12!bbbbbbbb13!
aaaaaaaaaaaaa12!bbbbbbbb1!
aaaaaaaaaaaaa12!bbbbbbbb2!
aaaaaaaaaaaaa!23bbbbbbbb12!
aaaaaaaaaaaaa!bbbbbbbb12
etc.

If anyone really wants to know why I need this... A very old .rar file of mine has a password in this format. Painful stuff guessing all this time.

I've written a little script that (hopefully) is what you need. I am not sure this was the right place for you to ask this, but here you go, anyway (This is a python 3 script):

string1 = "aaaaaaaaaaaaa"
string2 = "bbbbbbbb"
out = open("someFile.txt",'w+')
unkPos = ["1","2","3","!",""]
unkAllOptions = []
for x in unkPos:
    for y in unkPos:
        for z in unkPos:
            unkAllOptions.append(x+y+z)
unkAllOptions = [val for val in unkAllOptions if val != ""]
for unk1 in unkAllOptions:
    for unk2 in unkAllOptions:
        out.write(string1+unk1+string2+unk2+"\n")
out.close()

There are, of course, much better ways of doing this, that don't create duplicates and so on. But since the resulting word list is pretty small, I allow myself doing this the quick and dirty way.


Client Authentication by certificates in Google APP Engine java I am writing an application in Google APP Engine java which authenticate the user by its certificate. I have created a self signed certificate using keytool at client side. I also enable the HTTPS request in google app engine for my application. The flow of application is every simple.

When the user visits the homepage of application using any browser and then try to access a resource of application, I just authenticate the user if it has valid certificate. I am missing the part that how this certificate that I created at client side will be sent to the application when user access my application by any browser? Also How do I validate the certificate?

The point of user certificates is that there are things which are stored on the user side, in particular the user private key. Certificates for authentication will be used as part of SSL (HTTPS is HTTP-within-SSL).

In SSL things go the following way:

The client connects. The client and server talk to each other.
The server shows his certificate (which contains the server public key). The client verifies that the certificate is valid (properly signed by a CA that the client trusts; contains the intended server name; not expired; and so on) and then uses the server's public key to do the asymmetric key exchange from which is derived the session key used to protect the subsequent data flow.
The server may ask for a client certificate. In that case, the client should send its certificate (which contains the client's public key) and demonstrate mastery of the corresponding private key.

These steps are all done in the SSL protocol and you just have to let them run. Your job, though, on the server, is to validate the client certificate. What is that ? A certificate, by itself, proves nothing. Indeed, everybody can create a self-signed certificate with arbitrary contents; you just did it yourself. What makes a certificate useful is how it has been generated in the first place.

In your case, there are mainly three possibilities:

The server has a copy of all user certificates (not the private keys) and thus can compare the received certificate with all the known user certificates. A certificate is thus validated by virtue of being bit-to-bit equal to a known certificate. Since the certificate was created client-side, this requires an initial registration phase where the user presents his certificate to the server.
The server issues the certificates to the users. This means that in order to create a certificate, some code on the user side (e.g. in his browser) generates a private/public key pair, sends the public key to the server, and the server puts it in a brand new certificate along with the user name, and the server signs it. The resulting certificate is sent back to the user. Later on, when the user connects, the server recognizes the user certificate by virtue of it being signed by the server itself: the server uses its own public key to check the signature on the user certificate. If that signature is valid, then the server knows that the certificate contents are trustworthy, in particular the user name.
Same system as situation 2, except that the certificate issuance is delegated to another, dedicated system which will be called a Certification Authority. The user obtains his certificate from the CA, without involving your server at all. Your server can validate the certificate sent by the user by checking that it is properly signed by the CA; the server has a copy of the CA's public key, and trusts the CA for issuing certificates only to properly authenticated users.

Only the third case actually makes sense. Certificates are useful in situations where the assertion of identity (by the CA) is disjoint from the usage of said identity (in your server). If the server is itself the CA, then using certificates offers no advantage over a simpler password-based authentication (the "password" can be a long sequence automatically stored by the browser; this is known as a cookie).

If you are still intent on using certificates, then you must first be clear in your head about what a CA is, what it does, and where it will fit in your system.


SSL certificate chain verification After reading many articles and watching many tutorials I decided to be specific because there are some things about SSL certificate chain verification and SSL cetificate verification in general that I couldn't verify against all the tutorials I have read nor the ones I watched.

CASE 1:

Let me take a case where I own a certificate from Verisign, after the verification process they gave me a public/private key pair.

My server sends the public key(my certificate) to the browser, the browser own a copy of Verisign public key.

The following questions may seem stupid, but there isn't consistency among tutorials and everytime I try to understand I got myself into another corner.

How will the browser with Verisign public key is going to identify that my public key is indeed a valid Verisign key that can be used for encrypting messages that my Verisign private key can decrypt?, I assume its the Verisign public key digital signature that is tested against the server public key digital signature?, I may be wrong, but even if I am right I will be glad for a bit of clarification.
In case its indeed the digital signature that is tested I assume there is a relationship between all of Verisign public keys?, or maybe there is only relationship between each public key Verisign assign to a specific client(website/device/etc) and the public key the browser/operating system including.

CASE 2:

Intermediate certificates.

I understand that the need for them is security, so the root CA private key can stay offline, if there are more reasons i'll love to hear about them.
About the chain verification, I assume the server public key digital signature is tested against the server intermediate certificate digital signature, if its valid now it is the turn for the intermediate certificate digital signature to be tested against the browser/operating system pre-installed public key digital signature, and if this is also valid, the client has successfully validate both the intermediate certificate and the public key of the server.

I know i probably missed all up, if anyone can help me straight things up I will be very thankful.

It's not at all clear to me what you don't understand, so I'll take it very slowly.

First some terminology. It's important to get this straight, because otherwise you can't know correctly what you're hearing and saying.

Key pair: a private key and a corresponding public key which are mathematically related and used for public-key cryptography (PKC) also called asymmetric cryptography. For RSA, which is usually the only PKC someone knows when they don't specify, the public key consists of a modulus N which is the product of two large primes, and a public exponent E which can be and usually is small (in fact it usually is either 3 or 65537); the private key contains at least N and a private exponent D such that E x D = 1 mod phi(N); in practical use, the private key often contains additional values that enable faster computation, but there are quite a few other questions about that so I won't repeat them.

Digital signature: a value computed, for a specified chunk of data (almost always a hash of the "real" data) using a private key, such that the corresponding public key can be used to determine if the given signature is correct for the given data and could only have been generated by the given private key. This allows the verifier to determine that the data has not been altered or forged, and the data was sent or at least seen by the holder of the private key, but it doesn't say anything about who that holder is.

(X.509 aka PKIX) (Identity) Certificate: a data structure including a public key for an entity and the identity of that entity; plus some other information related to the entity and/or the CA; all signed by a (generally) different entity called a Certificate Authority or CA.  I hope you meant Verisign only as an example; it is one CA but not the only one; you can get an equally good Internet certificate from others like GoDaddy, Comodo, StartCom LetsEncrypt, etc. If you trust a given CA to issue certs correctly, then you can trust the much larger number of public keys and identities in certs it issues. Update 2017: StartCom is no longer good, since it was bought by WoSign who was then caught breaking CABforum rules and now is widely distrusted. OTOH LetsEncrypt is now widely-trusted, and free. Which further emphasizes the importance of having multiple CAs!

User (end-entity) certificate: a certificate containing the key and identity for  anything other than a CA, such as an SSL server, an SSL client, a mail system, etc.

(CA) Root certificate: a certificate containing the public key of a root CA. Since there is no CA "above" the root, a dummy signature using the CA's own private key is used, but that has no security value. You must decide (or delegate) whether to trust that key
"out of band", that is, based on reasons other than cryptographic computations.

Chain or intermediate certificate (and CA): (as your question indicates) most CAs now operate in a hierarchical fashion, where the root key is not used to directly issue user certificates. Instead the root CA and its root (private) key is used to sign certificates for several intermediate or subordinate CAs, each of which has their own keypair. Each intermediate CA can then issue user certs, or sometimes a second level of intermediate certs; this can be extended to several levels, but that's very rarely needed.

Since you mention a browser, you are apparently concerned (only?) with certificates (and keys) for HTTPS (HTTP over SSL/TLS). This is a common and important use of certificates and PKC, but not the only use.

Now, case 1. Since this case doesn't consider chain/intermediate, and Verisign does use that, I'll use a hypothetical SimpleCA instead. First, no CA ever has or sends you your private key. You generate your key pair and send your public key to the CA in a data structure called a Certificate Signing Request or CSR. The CSR also should contain your name; for an SSL server this is normally the domain name (FQDN) of the server. The CSR contains some other data you can ignore for now. The CA verifies your claimed identity (for SSL server, that you "control" the specified domain name), and usually collects a fee, and then creates a certificate which contains:

your name (here SSL server FQDN) as the Subject and/or one or several name(s) as SubjectAlternativeNames especially in recent years
your public key as SubjectPublicKey, and usually a hash of it as SubjectKeyID
a ValidityPeriod specifying how long the certificate is valid, chosen by the CA based partly on how much you pay them
the CA's name as the Issuer, and usually an AuthorityKeyID which also identifies the CA
some other data you can ignore for now

and this whole structure is signed using the CA's private key (which means it can be verified using the CA's public key). The CA sends this certificate back to you to use in your server along with the private key you already have.

Previously, assuming SimpleCA showed it can be trusted to appropriately verify applicants and paid a fee, the browser vendors (Microsoft, Mozilla, Google, Apple, etc.) agreed to include its public key with their browsers, normally in the form of SimpleCA's root cert. Now when some browser connects to your server and you send your cert which says in effect "Aviel-server approved by SimpleCA", the browser finds SimpleCA's root cert and thus SimpleCA's public key and uses that to verify that your cert is signed correctly, and that the server name in your cert matches the server in the URL the user wants; if both those pass, it accepts the public key in your cert as the correct public key for you, and uses it to complete the SSL/TLS handshake. If not it displays some kind of warning or error.

Unless, that is, your cert was revoked. If your private key is compromised, or if the CA determines that you no longer control the claimed identity (including if they discover you never did but deceived them on the application), the CA publishes that your cert is revoked and therefore browsers don't trust it even though the signature still verifies (because the RSA computation is a fixed mathematical process independent of time or environment).
But revocation, and if and when and how well it works, is a whole complicated topic by itself, and this answer is large enough already.
(edit) How does OCSP stapling work? covers revocation (actually both OCSP and CRLs) with ursine thoroughness. If your certificate is expired (past the end of its validity period) it is also invalid; this one is easy for browser to check. Formally a certificate can also be invalid before the beginning of its validity period, but in practice CAs don't issue 'post-dated' certs unless someone messes up the timezone or something.

However, the set of CA root certificates supplied in a browser is usually only the default; the browser user can decide to add new roots or delete existing ones if they choose. And if so that may make your server trusted when it wasn't before, or untrusted when it was before.

Case 2 (chain). One reason for intermediate CAs and thus intermediate or chain certs is keeping the root key offline as you say. Another reason is to allow the intermediate CAs to be managed much like users: they can have limited validity periods and be renewed, and if compromised (or just no longer wanted) they can be revoked, and this happens automatically and nearly invisibly. On the other hand if you have to extend, replace, or revoke a root, basically every browser in the world must be updated. That's a lot of work, and is never done completely because users will refuse or forget to install an update and be left trusting a CA that isn't secure and thus probably servers that aren't legitimate.
Also for revocations that are published the older way using a Certificate Revocation List (CRL) dividing the issued certs over multiple intermediate CAs makes CRL management easier.

With a single intermediate/chain cert, the process is changed as follows. Let's say VerisignServerB is issued under VerisignRoot and is used in turn to issue Aviel-server. (The actual names are longer, but this is easier to see.) Then your server is configured to send both Aviel-server and VerisignServerB to the browser. The browser checks that the VerisignServerB cert is signed correctly under the VerisignRoot public key (as before, normally stored as a selfsigned root cert), AND that Aviel-server cert is signed correctly under VerisignServerB public key from that cert, and that Aviel-server cert name matches the desired one. It doesn't matter which order the signatures are checked as long as both are.

SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?
has a nice graphical example of this which may help you.

For multiple intermediate/chain certs, when used, the extension should now be obvious.


Can a employee steal a company's SSL certificate private key? Is it possible to a rogue employee to just login in a company server and steal the private keys used to secure SSL connections? Is it as easy as copying a file?

(I've read some questions that the focus was what happens after a certificate was stolen. Here, I want to know how easy is to an insider get the private keys.)

Thanks.

Is it possible to a rogue employee to just login in a company server
  and steal the private keys used to secure SSL connections?

Yes, except when it's hard, or when it's impossible.

  Is it as easy as copying a file?

This is where the gradation comes in.  There are a wide variety of security levels, some of which I'll describe here from easy to hard:

In the easiest case, yes, the private key is a simple text (PEM) file, and may not even have proper file protections*
Or the key file might be stored with restrictive permissions.  Now the employee not only needs to be on the server, he needs to have the appropriate (Administrator or application) privileges to copy the key.
The key file might be password protected but automated.  This usually just means that in addition to the key file, the employee needs to find the config file with the password stored in it and steal that too.  (See also "java keystore changeit"...)
The key file might be password protected and the key entered at runtime by a human operator.  In this case, the password cannot simply be stolen from the system.  Of course, your employee might be an operator...  Also, in practical terms, very few servers are run to require human intervention upon restart.
If I recall correctly, IIS used to be able to import the key into a keystore that was not exportable by users, but would allow use by services.  Such things can generally be worked around with enough privileges.
Finally, if a Hardware Security Module (HSM) is used, that is designed to protect the keys even from the Operating System itself, to allow their use via cryptographic operations without exposing the keys to the computer hardware and software.  In this case, the employee will probably find the key impossible to steal.

  Here, I want to know how easy is to an insider get the private keys.

It's going to depend on the site, but in general, my experience has been that most sites store the key with nothing more than file permissions to protect it.  The general sense is "Well, if someone breaks into the server, they've already gotten everything, and we'll need to issue a new key anyway when we recover."  Of course, this ignores

the gap between compromise and discovery, and
the potential use of a private key to quietly read traffic in the meantime.

The shift towards ephemeral TLS ciphers is slowly closing that second gap, rendering the private key far less useful (snooping is often more valuable than impersonation; impersonation can be achieved in other (possibly simpler) ways).

*C'mon, guys, don't pretend you haven't seen a dozen poorly secured Apache configurations where the keys were left world readable.


With PBKDF2, what is an optimal Hash size in bytes? What about the size of the salt? When creating a hash with PBKDF2, it allows the developer to choose the size of the hash. Is longer always better? Also, what about the size of the random salt? Should that be the same size as the hash?

EDIT: Particularly in hashing passwords.

For the hash function, you want to use a function for which the most efficient platform type (the one which will produce the more hash computations per second and per dollar) is the machine that you intend to use (i.e. a PC). That's because you are in a weapon race with the attacker, and the attacker can buy other kinds of hardware to get an edge over you (such as a GPU). GPU are very good at 32-bit arithmetics, but not at 64-bit arithmetics, whereas a PC (in 64-bit mode) will be quite fast at the latter.

Thus, use a hash function which runs on 64-bit arithmetic operations. This points at SHA-512.

PBKDF2 is a key derivation function: it produces an output of configurable size. For password hashing, you want the size to be large enough to deter generic preimage attacks (i.e. trying random passwords until a match is found), so this would need, say, at least 80 bits of output. If only for making the security more convincing for the unwary, and also for aesthetics, go for the next power of 2: a 128-bit output. It is not useful to go beyond that.

The salt must be unique -- as unique as possible. An easy way to achieve unique salt values is to generate salts with a cryptographically strong PRNG: probability of reusing a salt value will be sufficiently low to be neglected if these random salts are large enough, and "large enough" means "128 bits". So use random 128-bit salts.

Personally, I prefer bcrypt over PBKDF2 for password hashing.


HIPAA compliance in web forums? If a website has a private forum (membership is not free) where people may ask health questions and paid Doctors are around to answer them, do normal HIPAA compliance rules apply?

In any forum, people are aware (or at least, they ought to be aware) that anyone else with access to the forums will see their posting. So I see little expectation of privacy, and people must be careful of the information they divulge.

The reason why I ask is some of the requirements (encryption at rest) seem to defy common sense in an environment where anyone can gain access to the data for the low price of $15. At the same time, they make it harder for the system to function (ex: how can one search encrypted data; or what existing forum package even encrypts its data?).

At the same time, these are Doctors answering questions, publicly displayed though they may be. And from my reading "covered information" is a very broad term. Even the statement "I'm sick" appears to be covered information if I'm reading correctly.

The HIPAA Privacy Rule "regulates the use and disclosure of certain information held by
"covered entities" (generally, health care clearinghouses, employer
sponsored health plans, health insurers, and medical service providers
that engage in certain transactions.)" Where a covered entity is a Health Care provider, a Health Plan, or a Health Care Clearinghouse. So the question is,
Are you a Covered Entity?
The site offers an Entity Chart .pdf for making that determination (it appears to be a flowchart of yes/no questions). Page 4 covers Clearinghouses - looking at the diagram, I'd say your website is probably not a "covered entity".
Naturally, I am not a lawyer, and you probably should consult a lawyer.


Is Windows 7's Remote Assistance feature secure? Are there known attacks that can intercept an ongoing Remote Assistance session, for example to take screenshots or even worse, impersonate the other computer and send arbitrary keystrokes, or to connect to an inactive session before the real person that is supposed to "assist" me connects ?

Background : I often use Remote Assistance to show stuff to some friends or to allow them to try/use a program that they either can't or don't want to install on their own machine, and I'm concerned about the security of all this.

According to this, assistance in windows 7 is based on RDP.

http://en.wikipedia.org/wiki/Windows_Remote_Assistance

  In Windows 7, WRA is based on RDP 7 and uses Peer Name Resolution
  Protocol when connecting using the Easy Connect option.

There exists a weakness in win 7 RDP, but its most likely been patched on a updated computer.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-0002

  The Remote Desktop Protocol (RDP) implementation in Microsoft Windows
  XP SP2 and SP3, Windows Server 2003 SP2, Windows Vista SP2, Windows
  Server 2008 SP2, R2, and R2 SP1, and Windows 7 Gold and SP1 does not
  properly process packets in memory, which allows remote attackers to
  execute arbitrary code by sending crafted RDP packets triggering
  access to an object that (1) was not properly initialized or (2) is
  deleted, aka "Remote Desktop Protocol Vulnerability."


Which attacks can a malicious hosting company execute? Which attacks can a rogue hosting company carry against the servers it hosts? Assume that the rogue hosting company also provides full access to law enforcement.

I was just wondering about that. So much effort people go though to secure their servers and all NSA needs to do is to force the hosting company to provide direct access, make them take a snapshot or whatever...

Also assume that you followed all good security practices, and you have downloaded and flashed the OS by yourself and it's up to date.

Also assume Full Disk Encryption, and DDR3 RAM memory.

I want to know mostly about attacks on run-time but at rest too.

Edit: to clarify I'm not asking about remote attacks a server normally faces from a hacker in his home, like a SQL injection or brute force on SSH. But attacks that are possibly only from the hosting company and nobody else. (One example I see is the hosting company taking a snapshot of your server and run it somewhere else).

Ok, in case of a VPS the ENTIRE server can be compromised, as one can clone and dump the state of the machine any time she wants. Even if you were to use encryption on disks, the keys would be in the memory and easy to retrieve. You could write your own patches to the system, but this would be StO.

If, however you owned the box, and just co-located it, you could, in theory have a much safer environment. Intrusion detection to the case and disks. Keys locking physical access to the front panel and hot-swappable disks. If you want real security go for this option.


What does the "period" of a random number generator measure? What is "period" in the context of pseudo-random number generators? For example when someone says "The Mersenne Twister has a 2^19337−1 period" what does it mean? I would appreciate a simple as possible explanation as possible.

What exactly is meant by "state" of a PRNG? On wikipedia I found "The sequence is not truly random in that it is completely determined by a relatively small set of initial values, called the PRNG's state, which includes a truly random seed."

As others have explained, the "period" measures the number of output bits (or "words", depending on terminology) after which the PRNG begins to repeat itself. For some PRNG this is relatively ill-defined. A PRNG is a deterministic algorithm with a state (the contents of its internal buffers and counters and variables). The sequence of subsequently emitted bits entirely depends on that state. If the PRNG uses a finite state (i.e. it fits in a fixed amount of RAM, without unbounded dynamic memory allocation) then it will mathematically begin repeat itself at some point, because there are only finitely many possible values for the complete state.

Not all PRNG are reversible. The PRNG is deterministic, meaning that from a given state value S, the next output bit and subsequent state S' can be unambiguously computed. A reversible PRNG is such that given state S, there is a unique previous state S'' for which S is the successor. LFSR are traditional reversible PRNG.

An example of non-reversible PRNG is the following hash-based PRNG:

We use a hash function h, with a n-bit output.
State S is a buffer of n bits.
To produce the next bit, we compute h(0||S) (hash of the concatenation of a bit of value 0, then S); the first bit of the output is the next bit; then we compute the new state S' = h(1||S).

Please note that this is just an example; I do not claim cryptographic security of that PRNG. Since there are only 2n possible values for S, we must necessarily encounter an already-seen state value after at most 2n+1 steps, so the "period" will be no more than 2n. However, the function which computes h(1||x) from x is not a permutation; it is expected to have collisions. This implies that when the PRNG "loops", it is rather improbable that it loops back to our initial state value. Instead, we expect (on average, depending on the hash function h) that such a PRNG will loop on a cycle of length about 2n/2; and we will reach that cycle after again an average 2n/2 steps. This implies that the first 2n/2 produced bits will (probably) not be repeated.

In that sense, the "period" does not measure all that is to be known about a PRNG. In fact, it is mostly impractical: in the hash-based example above, the "period" cannot be readily measured, and describes behaviour of the PRNG in conditions that will not actually be reachable in practice.

The important point here is that period is not a measure of security. Cryptographers do not care about the period. Period says anything about the security only in the special case that it is so short that it can be realistically explored. However, any period beyond 264 or so is "large enough" and becomes irrelevant.

In fact, if the description of a PRNG talks about the period, then it is a very definite indication that the PRNG was not designed or analysed by a cryptographer, and does not aim at cryptographic security (and usually won't provide it either). Indeed, the Mersenne Twister is meant for big physics simulation jobs, where there is no attacker to defeat except a mindless Nature. Cryptographers are more demanding, since they want to thwart an intelligent enemy who tries real hard to guess the next bits.


Is truecrypt a good choice to work with file that are generated and manipulated via browser i'd like to know if Truecrypt is a reliable software for filesystem encryption, at the level of pgp as security level, and if it suitable to work with files that are generate via web browser, so through server side o client side languages, for keeping encrypted theses files on a filesystem.

Moreover using a software like this, would you keep a security not encrypted copy of your private data, for example on a dvd or a usb hard disk, in case of software failure or error, or you would only rely on the software ?

How much is Truecrypt reliable ? Can it be cause of data losses, due to a malfunction, I mean not due to a forgotten password, but to an internal error of the software ?

Thanks

As I've commented, I find your first question a bit vague, so I'll go on with the rest:

  Moreover using a software like this, would you keep a security not encrypted copy of your private data, for example on a dvd or a usb hard disk, in case of software failure or error, or you would only rely on the software?

  How much is Truecrypt reliable ? Can it be cause of data losses, due to a malfunction, I mean not due to a forgotten password, but to an internal error of the software ?

Truecrypt is widely used, but you can never guarantee that it's completely free of bugs. For example, when it's in the middle of a write operation and the power fails, the disk won't complete the write, possibly leaving the file corrupt. Not Truecrypt's fault, but it can happen.

So yes, if the data is important to me, I would always keep a backup. You can keep an unencrypted backup, but what's wrong with storing an older version of the encrypted file? (Truecrypt stores the encrypted virtual drive as a single file.) Mount the file, read/modify it, and unmount it when you're done, just like you normally would. Then, test if you can decrypt the saved file (so that you know it's stored correctly), and copy the file. That makes sure you won't loose (much) data because of something caused by Truecrypt itself. The more regularly you copy the file, the less work you could loose of course. Just like with normal backups.

Then there are issues like drive crashes, the chance on fire... So an off-site redundant backup would best protect your data (all the wile keeping it encrypted). Just like with normal backups.


OWASP ZAP API HTTP Sessions setup I'm trying to create a script using the Node ZAP SDK. The script needs to perform an active scan of the site on localhost while signed in as a super admin; if no user is signed in, it can only reach about 3 of the 50 or so available pages.

I have the entire script working, except for signing in as the user. Now, when I do this in the ZAP desktop client, I just open up Firefox and sign in to the site myself and the session is automatically set up as an HTTP Session and I'm trying to duplicate that using the API. Here is what I currently have:

const ZapClient = require('zaproxy');
const cliArguments = require('minimist')(process.argv.slice(2));
const execSync  = require('child_process').execSync;

const zapOptions  = {
    apiKey: cliArguments.apikey,
    proxy:  'http://127.0.0.1:8080'
};
const zaproxy     = new ZapClient(zapOptions);
const site        = 'https://127.0.0.1';
const sessionName = 'zap_session';
const cookieName  = 'site_session';

function createSession(resp) {
    // generate a valid cookie for a user that exists in the system with admin rights
    const userCookie = execSync(
        `/command/to/generate/valid/cookie ${cliArguments.userid}`,
        {cwd: __dirname}
    ).toString();

    return zaproxy.httpSessions.createEmptySession(site, sessionName)
        .then(resp => zaproxy.httpSessions.setActiveSession(site, sessionName), handleError)
        .then(resp => zaproxy.httpSessions.addSessionToken(site, cookieName), handleError)
        .then(resp => zaproxy.httpSessions.setSessionTokenValue(site, sessionName, cookieName, userCookie), handleError);
}

There's a lot more to the script, but this is the session creation. If I call for the activeSession after this, I get a response of zap_session like I would expect. But when I run it and log all cookies in my application, no cookies are passed to the site and both the Spider and Active Scan fail to scan anything beyond the login page. I've managed to get it working a few times, but it only ever works for one run and then fails every subsequent run (it seems to work when also removing the session before createEmptySession, but that doesn't consistently happen either).

Does anyone have any insight into what the correct process for this is? The API documentation is extremely poor and I've had trouble finding any examples of this online anywhere (even using other languages). It seems strange to me that I need to make 4+ API calls to set a single session token which makes me feel I am completely wrong with my approach, but I just have nothing to judge myself against.

"I just open up Firefox and sign in to the site myself" - this can actually cover a huge multitude of sins.

There is no one standard way that websites implement authentication, there are lots. While we would love ZAP to be able to understand all of them we just don't have enough people to implement that.

Which means that you will need to understand how your application authenticates you.
If it is a simple form then it might be relatively straight forward - have a look at https://www.zaproxy.org/faq/how-can-zap-automatically-authenticate-via-forms/

If it is more complicated then ZAP should still be able to handle it but we'll need more info. I've started covering authentication in the ZAP in Ten videos: https://www.alldaydevops.com/zap-in-ten

If you need more help the ZAP User Group is probably a better forum: https://groups.google.com/group/zaproxy-users


Is it risky to use an untrusted keyboard? Suppose you're buying a new keyboard (say USB-wired, but consider Bluetooth connected as well) from Ebay. Is it risky to use that keyboard in a sense that it could be more than just a keyboard?

Thinking of USB rubber ducky (see also here) which is a USB pen drive that registers as a keyboard and can send arbitrary keystrokes I can similarly imagine a keyboard that logs every single keystroke and then - perhaps after a while of inactivity - changes its mode to USB mass storage and with the help of some auto-run or thumbnail parser exploit sends all the logged key strokes to some malicious server, potentially leaking all the logins and passwords that were typed on that keyboard.

So my question is about both USB and Bluetooth connected keyboards and whether such scenarios are realistic hence implying a security risk of using unknown / untrusted keyboards (obtained from third parties).

I think you have answered your own question :) Purchasing hardware from any untrusted supplier carries risks. The company I work for has a designated hardware supplier for peripherals (And other hardware) to help mitigate against this risk (amoungst other controls).

There have been incidents before where keyloggers have been installed on keyboards, see https://thehackernews.com/2017/05/hp-audio-driver-laptop-keylogger.html

Avoid if possible & if you are unable to avoid then make sure you have the necessary security controls on the device before plugging in, better to be safe than sorry.


Security on a PEAP wifi network on phone I use my office network for snapchat, facebook etc
My office network uses PEAP as an EAP method.
And uses system certificates while connecting

It requires me to connect to the domain that is my  companyname.com
and then the office provided user credentials.

Is this is a secure connection?Can they see my snaps , chats etc.?

Any help is appreciated.

Thanks.

PEAP will secure the connection between your wireless client and the wireless access point relatively well. Whilst probably not your concern, the weakness in this system is the identification of users - usernames and passwords used for PEAP can easily be re-used on devices, whereas EAP-TLS would provide stronger authentication through the use of certificates.

What you are probably interested in is the security of your data from your wireless client through to the internet. The strength of your wireless security (between your wireless client (WiFi Cli) and the wireless access point (WiFi Ap)) tells us nothing about the security of your company's internal network.

           |-------- Office Network --------|

WiFi Cli <---------------> WiFi AP <----------------> Internet

              Secure                    Unknown?

If you are connecting to a HTTP website, the reality is your company can see all of the content in clear-text relatively easily.

If you are connecting to a HTTPS website, your company probably can't see all of the content (without a HTTPS inspection on a capable proxy) - but they can see what the name of the site is. This means they could see you are using Snapchat or Facebook generally, but not the contents of the pages, messages or images you send/receive.

Whether you should be using it for that purpose, however, is another question entirely!


Site listed as hacked by a hacking group I was Googling one of my domains (hosted on shared hosting) and found a webpage where it was list as Hacked Site, the list belonging to a certain national hacking group (the country they claim to belong is notorious for lot of international troubles, but the country, as such, has no accords in hacking World).

Only the root index page is public while rest of the data is protected by HTTP Authentication. Moreover, each page (in addition to logging by the cPanel) also has its own visit logging script which logs visit data to the DB and neither of the two logging mechanism show an unusual activity during the past few months. Also none of my files seem to have been affected or altered.

As of writing, I have blocked all access to most of the folders/data completely and changed passwords and username for the once not blocked. The domain is primarily used by us for testing and experimentation.

Is this possibly a false claim? (There is very little to suggest an intrusion going through logs and state of the files, db etc.)
How can I better diagnose the situation?
Given that it is on hackers list, should I abandon the domain and/or host?

It could very easily be a false claim - and it sounds like you have done the right things regarding checking logs, database etc - and you can perform in-depth forensic analysis (either yourself or contract one of the many companies that do this) but if you are in any doubt you should plan for the worst - a rootkit.

If you have a well concealed rootkit, the only option is to completely wipe the machine and start again from known good sources.

Your point about a hacker's list depends on what they are saying. If it is purely a 'we defaced/pwned these sites' list, then I wouldn't think anything of it once you have secured it.


Which exploit types does software diversity have a benefit against? This classical paper of Paul van Oorschot: Revisiting Software Protection, mentions in section 3.4 that by employing software diversity "an exploit crafted to succeed on one instance will not necessarily work against a second" software instance.

I know that software diversity does not eliminate the possibility of re-executing an attack on a different/diverse software instance. It simply causes an exploit built for one software instance to (possibly) not work against another software instance that has the same function.

My question is when will an exploit for one instance not succeed on a different instance? What kind of attack performed by an exploit will fail if software diversity is employed?

I've seen many papers stating that software diversity protects against code-reuse attacks, with Return-Oriented-Programming and Jump-Oriented-Programming being given as an examples. I'm wondering if there are some other attacks which diversity protects against as well.

One example would be a buffer overflow attack. These are often very specifically targeted against specific versions of application software. If you had an exploit that worked against IIS 7.0, that same exploit would not also work on Apache.

A counter-example would be a cross-site scripting attack, which only attacks the client's browser, and is agnostic to the internal applications.

With a homogenous ecosystem, a virus that can infect one vulnerable system can easily spread to infect all identical systems, or an exploit that can be run one one machine can be scripted to run on many.

Diversity provides redundancies, and they can help limit your damage. If you have two brands of gas pumps in your store and a virus starts stealing credit cards, it may only steal half of your customer's cards.

The drawback to diversity is if it presents two attack surfaces for an attacker to choose from. The gas pump example above is one such scenario. As an attacker, I can try attacking the easier of the two pump softwares, and if I breach either, I get to steal half your credit cards. As a thief, stealing half your gold is still a lot of gold, and is worth it.

EDIT

Diversity is now less valuable than this paper suggests.  As security practices have dramatically improved since 2003, threats have become increasingly sophisticated as well.  The paper concerns itself only with "dumb" attack vectors such as viruses, which were a bane a decade ago, but thanks to improved security are now far less successful than they were then.

Modern threats are targeted and tailored to the victim system.  They identify the software through fingerprinting methods, then craft an attack designed to defeat it.  Tools like autopwn mean that a diverse environment simply provides extra chances for a system to be vulnerable.

Diversity takes advantage only of security through obscurity.  A diverse system might be considered safe only because so few of them exist that an attacker has never bothered to explore it fully to find its weaknesses, or that the target is of such low value that there was no reason to attack it.  Advances in botnet technology mean that even ultra-low-value targets like refrigerators or thermostats can deliver value to an attacker either through spamming activities, or perhaps as a target for ransomware, so they're becoming increasingly studied by attackers for vulnerabilities.  That means that a thermostat's cloud service on your home network may end up being the entrypoint for an attacker to get behind your firewall, where he can attack your banking PC at his leisure.  In this case, diversity unwittingly enables the attacker.

Up until not too long ago, I had thought diversity was a good strategy.  After watching attackers ply their trade, I am now convinced that it's almost irrelevant, and that effective security practices need to remain the primary focus of security teams.  Simplifying systems, reducing their attack surfaces, application reviews and security analyses, separation of duties, isolation of credentials, key and certificate management, and clear security policies, those are the effective practices.


Is a parcel letterbox based on a tracking code secure? I'm making a parcel letterbox. I'm including a barcode scanner that scans the tracking code of the package. The way of entry is simple: by scanning a barcode that's in a list on a local server (which the letterbox downloads in advance to decrease latency). This barcode is normally the tracking code on a parcel.

If the tracking code of the package is in a list, the courier can open the door and can put the package in.

If the tracking code is not in the list, the courier (or whoever else is trying to get in) will be denied entry.

For myself, I use a card with a barcode on it or a manual override (traditional lock).

My question is simple: is this a (relatively) safe way of doing this? Tracking codes aren't specifically protected, but at the same time are not made public either. So based on my simple (simplistic?) reasoning, this is a relatively secure and convenient system. Or am I missing something?

Just to be clear: I'm specifically asking about the way of entry. Assume the letterbox is properly secured, that the door and lock are secure, etc.

I would strongly consider encrypting the barcode lists on your server and on your letterbox, if either of these devices have vulnerabilities that allow an attacker to get that list, they essentially have a list of access tokens and your security is comprised.

You should secure the communication between your client and server and ensure your device checks certificates when it retrieves the new barcodes. Attack vectors here being man in the middle sniffing of access tokens (your barcodes) and illicit devices sending you fake tokens if you don't validate the sender. You could consider digitally signing the updates and validating the signature

I'm also thinking of barcode validation, it seems theoretically possible that a sql injection attack could happen with a malicious barcode. Santisation of input, parameterised procedures etc will help mitigate but you may want to research further.

You also need to revoke tokens one they are used. When your delivery driver figures out he can photocopy a barcode and reuse it, security is compromised.

I'm not sure how many possible barcode combinations there are,  I imagine it depends on the specific scheme, but you should probably change your own tokens regularly and consider 2FA.

Hope that helps.


On urlscan.io Indicators of Compromise, what do the hashes represent? When I look up a domain of interest on urlscan.io, I see a lot of interesting information.
When I click on "Indicators of compromise" (IOC), I see a list of hashes that are actually links to pages full of information that I don't understand.
Example page:
https://urlscan.io/search/#hash%3A1e85ec81b9800b4c443d39caca0d0926089a3ac201120db1ceb45b93789480b8

nothing there seems to have anything to do with the domain I started investigating.  So, what is this page and what does it mean for the domain of interest?

This site uses an unusual understanding of the term IOC (Indicators of compromise). Essentially it just lists all resources it has found on the site, no matter if these actually indicate a compromise or not. Just try some known innocent sites like example.com and you still find  "IOC" reported.


Setting expectations of a vulnerability assessment? Is it reasonable to refuse to guarantee that you will find 100% of security issues when doing a vulnerability assessment on a website?

Even with companies like Google that have teams of security professionals, an occasional security vulnerability slips through.  There are also zero day security issues with third party software that are not realistically findable when doing a vulnerability assessment.

Considering the above, what is a reasonable position to take when doing a vulnerability assessment regarding finding all security vulnerabilities?

From the InfoSec perspective it's perfectly reasonable. No surgeon can (or should!) guarantee a 100% safe operation, no lawyer can guarantee conviction or acquittal.

Of course, the customer doesn't want the InfoSec professional to take their money and hide behind that clause in their contract either, if something were to slip past the audit.

I'd suggest that the solution to the issue is exactly what you mentioned - setting the right expectation. The customer should expect that the InfoSec team will do their very very best to detect common, easily exploited vulnerabilities. There are many ways to signal that you truly intend to do your best.

Financial guarantees specific to the scope of the audit request: e.g. 100% refund for a SQL injection exploited post-audit.
Reputational guarantees: e.g. "Secured by ACME InfoSec" text on their website, so that the InfoSec professional has a vested interest in keeping the site secure.
Multiple-audit guarantees: e.g. Offer to have a competing InfoSec firm provide a second opinion for comparison.
Testimony: From other customers whom you have helped in the past.
Proof of Work: Demonstrate actual effectiveness of your recommendations. e.g. Have independent pen-testers attack before and after your recommendations are implemented.

Of course, this all depends on a customer that understands that the only certainties in life are death and taxes.

For those that insist on 100% guarantees, you could certainly provide those within scope (point #1 above). You could (and should) include a maximum liability clause - e.g. the most that you will have to pay is $x.


Who SHOULD write crypto code? I've seen a lot of questions and answers acknowledging the dangers of inventing your own crypto algorithms — and even of implementing proven algorithms yourself. And, I don't disagree. I might even argue most of us don't even know how to safely use the existing libraries!

But, who should do it? What education, experience, or environment warrants writing your own crypto?

We dogmatically tell everyone who asks "don't roll your own! Use an existing library" But, somebody writes cryptographically secure algorithms and code. Who?

Who wouldn't we scold for "not using an existing library"? (And why do we trust them?)

As an aside, is there any place for the "common" developer to learn and contribute in a safe and beneficial or non-destructive manner?

You noticed the unfulfillable requirement: you are never told that you are ready to write crypto code.

I think the reason the "never roll your own" recommendation is always advised is because one is seeking recommendations.   As a lower bar, the point where you no longer rely on public opinion for advice is when you can start thinking about crypto.

And, at that point, you fully assume all responsibility for what you create.  The social group of developers never told you you could do it.  You just decided to do it.  And you live with the consequences.

Now, more specific than that, several experts recommend first trying to break other's crypto libraries before trying to write your own.  Once you can break what's out there, you are more likely to be aware of all of the nuanced pitfalls that come with writing your own library.

But myself, I think of it with a martial arts metaphor.  Think of an art where the black belt test is notorious.  It shreds egos like it was As Seen On TV.  You only get to take the test once.  So many ask "am I ready for the test?"  And the answer is invariably "You are never ready for the test."

So when  are you ready for the test?  When you realize you don't need a test to let people know you're good enough to be a black belt.  You know it.  So you just put on a black belt, stare down the experts who were supposed to give you the test, and they nod as if to say "yep, that was the trick the whole time."


Is WCF or Java Metro security configuration in-scope for your security department; should it be? Windows Communication Foundation (WCF) is a set of technologies that expose server-side executable code and data over the Internet.

Given the port sharing abilities of IIS, or even that a web developer can host a WCF application unbeknownst to the IT security team, I think that the IT security team should have some control over what is exposed and it's configuration.

Examples of WCF configuration include: Protocol choice, encryption method, and which executable methods are exposed.

Do you agree that this technology should be considered in-scope for the IT Security Team.
How would you sell this to management for inclusion (given that you're not a manager)
What processes would you put in place for auditing and deploying this technology?
How would you define support boundries with the application team?
... other items

Part of the reason I ask this question is that at the large companies I worked for, SOAP security was out-of-bounds for the same group that handled perimeter security (often the same group who handled the firewalls and routers).

Perhaps the size of the organisation should be taken into account when asking this question.  Is it unreasonable to expect a Firewall administrator to also understand WCF/Metro?

Yes, of course.
It's the same as a code review, or a deployment inspection.
During CR, I would expect configuration files to be part of the code base that is examined; and during a deployment inspection, all configurations you can get your hands on should be opened up and examined.

That also answers no.2 - explain to the manager that its part of the previous reviews.
3. Again, same as above - if you have a process around CR or DI, those should be part of that.
4. Boundaries: and here is a needed clarification - the dev team is responsible for performing the configuration, SecTeam has oversight, verification, and of course is additionally in an advisory/educational status.

Wrt the addition of your edit, network/OS security guys really cant do anything with WCF, and shouldnt be expected to. I was referring to the AppSec team, or security architecture, or whatever you want to call them.
Same goes for (most aspects of) SOAP, its an application protocol, network guys just wont know what to do with it.


Why gethosbyname() is as bad as gets() by design? I know gethosbyname() has been obsolete for a long time. But I see static analysers report its use as unsafe, and when softwares remove its usage, it tends to be for security reasons.

I know there were a lot of security flaws found inside implementations recently (like ghost), but several things seems to indicate that the function is also flawed by design…

Deprecated functions are generally tagged by static code analyzers simply because they're deprecated. (That's usually an optional setting.) Many secure coding standards specifically state: "do not use deprecated functions."

Apart from some long-ago-fixed bugs, gethostbyname isn't terrible, but that's no reason to use it in new code when a supported alternative exists.


What are the differences between TPM and HSM? TPM (Trusted Platform Module) and HSM (Hardware Security Module) are considered as cryptoprocessor, but what are the differences exactly?

Does one of them has more advantages than another?

Trusted Platform Modules

  A Trusted Platform Module (TPM) is a hardware chip on the computer’s motherboard that stores cryptographic
  keys used for encryption. Many laptop computers include a TPM, but if
  the system doesn’t include it, it is not feasible to add one. Once
  enabled, the Trusted Platform Module provides full disk encryption
  capabilities. It becomes the "root of trust" for the system to provide
  integrity and authentication to the boot process.  It keeps hard
  drives locked/sealed until the system completes a system verification,
  or authentication check.

  The TPM includes a unique RSA key burned into it, which is used for
  asymmetric encryption. Additionally, it can generate, store, and
  protect other keys used in the encryption and decryption process.

  Hardware Security Modules

  A hardware security module (HSM) is a security device you can add to a system to manage, generate, and
  securely store cryptographic keys.

  High performance HSMs are external devices connected to a network
  using TCP/IP. Smaller HSMs come as expansion cards you install within
  a server, or as devices you plug into computer ports.

  One of the noteworthy differences between the two is that HSMs are
  removable or external devices. In comparison, a TPM is a chip embedded
  into the motherboard. You can easily add an HSM to a system or a
  network, but if a system didn’t ship with a TPM, it’s not feasible to
  add one later. Both provide secure encryption capabilities by storing
  and using RSA keys.

Source: https://blogs.getcertifiedgetahead.com/tpm-hsm-hardware-encryption-devices/


Better than brute-force way to find the "lowest" sha1 hash? While pointing out a SQL injection flaw on another question, I was able to show that an arbitrary sha1 hash could be inserted into a query such that it would be taken for a real hash, and was therefore able to login assuming the dummy hash was used. I could inject an ORDER BY but then wanted to make sure the hash I was using as an example was likely to come out at the top.

From my understanding, 0000000...0 should be a valid possible output from the hash function but, of course, finding the associated input is non-trivial.

In any case, it got me wondering. Is there any way - except brute force or downloading a rainbow table  - to find a hash that would sort before an arbitrary point (say before 99% of passwords =~ in the first 1.46150x10^46)

I suspect the answer is no but would like confirmation.

If there is a method faster than brute force, it represents a weakness in the hash function.  Essentially what you're looking for is a modified preimage attack, just for a group of hash values rather than a single value.


How safe are signed git tags? Only as safe as SHA-1 or somehow safer? How safe are signed git tags? Especially because git uses SHA-1. There is contradictory information around.

So if one verifies a git tag (git tag -v tagname), then checksouts the tag, and checks that git status reports no untracked/modified files, without further manually auditing the code, how secure is this actually? Is it only as safe as SHA-1?

Let's assume an adversary, that is capable of producing SHA-1 collisions.

Linus Torvalds said.

Git uses SHA-1 not for security

And goes on.

The security parts are elsewhere

Could you please elaborate on this? Where are the security parts? Can you please briefly explain how these work? Where can I read more about this?

Wikipedia says.

Nonetheless, without second preimage resistance of SHA-1 signed commits and tags would no longer secure the state of the repository as they only sign the root of a Merkle tree.

(preimage resistance | Merkle tree)

Which contradicts what Linus Torvalds said. What does that mean for security? Which statement is true?

Sources:

Linus Torvalds explains a bit on youtube
Or excerpt of it as text.

The source control management system Git uses SHA-1 not for security but for ensuring that the data has not changed due to accidental corruption. Linus Torvalds has said, "If you have disk corruption, if you have DRAM corruption, if you have any kind of problems at all, Git will notice them. It's not a question of if, it's a guarantee. You can have people who try to be malicious. They won't succeed. [...] Nobody has been able to break SHA-1, but the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, OK, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get. [...] I guarantee you, if you put your data in Git, you can trust the fact that five years later, after it was converted from your hard disk to DVD to whatever new technology and you copied it along, five years later you can verify that the data you get back out is the exact same data you put in. [...] One of the reasons I care is for the kernel, we had a break in on one of the BitKeeper sites where people tried to corrupt the kernel source code repositories."

Update:
Got an verbose answer from Mike Gerwitz, the author of A Git Horror Story: Repository Integrity With Signed Commits:

https://forums.whonix.org/t/security-git-general-verification-verifying-whonix-submodules/513/12

There is no contradiction. Linus himself said in that same talk:

  If I have those 20 bytes, I can download a git repository from a
  completely untrusted source and I can guarantee that they did not do
  anything bad to it.

I'd interpret the "Git uses SHA-1 not for security" as "SHA-1 hasn't been added to git for security reasons, but for reliability reasons, but security still is a nice side effect", and "The security parts are elsewhere" as "the final verification is done by gpg, and git verify-tag".

Git commit ids aren't "more secure" than "bare" SHA-1. However, the use cases git is used for are more resistant against collision attacks, than most other SHA-1 use cases.

For example, SHA-1 in certificates is dangerous. Somebody could create two certificates with the same hash and for different domain names. One (the "legitimate" one) is sent in a CSR to a CA, and the other one kept private until used on some victim with the signature from the CA. For collision attacks, if the attacker changes the preimage at one part (like the domain name field of the cert), they must also change it at another position. While the attacker had free choice for the two domain names, the other changes are mostly fixed. Particularly, they are binary, and can't be part of any human-readable part of the cert. Some attacks hide them in the public/private keys of the cert (discussion for MD5).

Git however, is mostly used for source code. Hiding your {chosen-prefix,} collision in an ASCII diff reviewed by humans is much harder. Maintainers usually ask questions when you make an if-condition about the hex address 2ff5e of the file logo.png you added in the commit. Taken together, it is easier to hide a backdoor inside a commit, than to attack SHA-1.


How does a Web Security Gateway analyse SSL Encrypted Traffic? Since HTTPS traffic is encrypted in transit how does a web security gateway analyse it?

Products which purport to be able to filter SSL-encrypted traffic usually do so by doing a man-in-the-middle attack, just like an active attacker would do. The "security product" sits on the Web proxy, through which the connection is performed. It intercepts the flow, and generates on-the-fly a custom certificate with the name of the target site; the client effectively establishes a SSL tunnel with the proxy, not with the intended target site. Simultaneously, the proxy connects to the target site, and forwards data in both direction.

This can work only because the automatically generated certificate is signed relatively to a special certification authority controlled by the proxy, and installed as a "root CA" in the relevant store in the client machines. This requires that whoever installs the proxy has administrative control of the client systems.

Apart from such "security products", such an institutional MitM setup is found in products which claim to "speed up the Internet" (i.e. they grab the data, compress it, and send it to a specific gateway which uncompresses it).

Note that such a system cannot work with bi-authenticated SSL connections (the kind where the client also has a certificate): the client-generated signature cannot be converted by the proxy into a signature which will convince the server (because, among the data signed by the client, is the server certificate as the client saw it, i.e. the one automatically generated by the proxy).

Another way to analyze SSL-encrypted traffic, not on the client side but on the server, is to have a product which has a copy of the server private key, and ensure that the server does not use the "DHE" cipher suites. Under these conditions, it suffices to grab a copy of the packets to decipher the tunnel. Of course, this is for connections to one specific server, and it requires some cooperation of the said server (the server private key is, after all, private to the server).


Localhost intercept not working for burp suite I configured my Firefox proxy to send my php website traffic running on localhost to burp suite for intercept but its not intercepting anything. My Firefox and Burp Suite configurations here. I've tried using different port other than 8080, went to about:config and enable localhost hijacking but still it wont work. Days ago it was working fine but now its not.

As you can see in the screenshots you provided, your Firefox is configured wrong. The bottom section states

  No proxy for:

localhost, 127.0.0.1

This means that Firefox will ignore proxy settings for these addresses. Since you explicitly want to intercept traffic going to these addresses, remove them, and it will work.