Inside{CurlyBraces}

The Controversial Practice of SSL Inspection - A Betrayal of Trust?

2022-06-22T16:47:00+00:00

There’s a thin line between safeguarding corporate assets and invading personal privacy. One of the practices that continually straddle this line is SSL Inspection, a controversial technique utilized by organizations in the name of security. While it might seem like a fair move to protect proprietary information, let’s dive into why this technique is often seen as intrusive and potentially damaging.

SSL inspection, or SSL/TLS interception as it’s also known, involves the decryption, inspection, and re-encryption of supposedly secure (HTTPS) internet traffic. In simple terms, it’s akin to intercepting sealed letters, reading their contents, and then resealing them before they reach their final destination.

This measure, while painted as a security protocol, is more akin to a betrayal of trust. It raises severe privacy concerns and challenges our perception of secure browsing. SSL certificates were initially created to ensure secure communication between two parties, offering a sanctuary of privacy in the chaotic and vast digital world. To manipulate this secure channel for inspection directly contradicts the very essence of its creation.

Companies may argue that SSL inspection is a necessary evil, a method for blocking malware or preventing data leakage. While these are valid concerns, the crux of the matter lies in the sheer scope of the information a company can access through this method. Personal communications, sensitive data, login credentials, even financial information – all can be read and re-encrypted without the user’s knowledge.

This practice not only infringes on privacy rights, but it also raises several technical issues. Firstly, it can actually make users more susceptible to certain cyber-attacks. SSL inspection requires the installation of an additional trusted root certificate on the user’s device. If this certificate were to fall into the wrong hands, it could be used to conduct more sophisticated attacks.

Moreover, it can degrade performance. The inspection process places an extra burden on network hardware, potentially leading to slower connections. Ironically, this creates a paradoxical situation where a security measure ends up degrading the user experience, an outcome that could lead to even more significant security risks if users seek ways to bypass the system altogether.

It’s essential for companies to maintain a balance between security and privacy. While the intent behind SSL inspection may be well-meaning, it’s important to question whether it’s worth the potential damage to trust, privacy, and even the security it promises to uphold.

Instead of resorting to such intrusive measures, organizations could invest in user education and promote good cyber hygiene. Perhaps the key to a more secure digital landscape lies not in policing every move, but in fostering a culture of responsibility and understanding.

Let’s ensure that the SSL in HTTPS stands as a beacon of security, not an illusion of it.

Attaching Windbg to Managed Application

2017-04-10T16:47:00+00:00

You may want time to time dig into the implementation detail of the code you are working with(e.g. how they are represented in RAM). Windbg with the help of SOS extension gives you lot of those implementation detail. But when the initial breakpoint is hit the CLR has not yet been loaded and Windbg doesn’t allow you to load SOS. What you can do here is that temporary set a Console.ReadLine() in your code and hit Ctrl + Break to break the debugger at your desired location.

Launch the executable from WinDbg, and then input “g” command to let debuggee process to continue until readLine statement. press Ctrl + Break or use menu->Debug->Break and then input command .loadby sos clr to load the SOS extension.

The Infinite Loop Technique

In case you are not working with a console app and you still need to break into a specific location you can use infinite loop technique. In this technique, you are injecting temporary infinite loop, based on the value of a global Boolean flag, into your code.

When you hit g in the debugger it will stop at the infinite loop. You can then break into the loop and set the boolean flag to true in memory window. To track the location of the local variable in the stack you can use !clrstack -a command. After setting the variable to true you can continue the execution by hitting g command to get out of the infinite loop.

VS Code Integrated Terminal with Visual Studio Command Prompt

2017-01-21T00:43:00+00:00

It is quite convenient to use visual studio developer command prompt from VS Code integrated terminal.

You need to find the correct command line argument to start the visual studio command prompt. You can do that by checking properties of the shortcut icon.
Copy the shortcut link text

    %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat""

Then go to user preferences of VS Code and update the ShellArgs property with correct parameters you copied from the step 2.

    "terminal.integrated.shellArgs.windows": ["/k", "C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\Tools\\VsDevCmd.bat"]

If everything goes ok you should be able to use developer command prompt within VS Code integrated shell as follows

Troubleshooting

If you have trouble executing commands you can check if correct command parameters are passed into the integrated terminal by using the process explorer.

If you are running an older version of VS Code you may need to upgrade to the latest version due to this bug

Transport Layer Security (TLS)

2015-05-13T05:42:00+00:00

What is Transport Layer

In the Open Systems Interconnection(OSI) model the transport layer is most often referred to as Layer 4. It resides between network layer and session layer. Almost all modern authentication protocols rely heavily on transport layer security.

What is Transport Layer Security (TLS)

TLS is a protocol designed to provide communications security over a computer network. It is the successor of the SSL. The protocol is defined here. It can provide privacy and data integrity between two communicating applications.

Why it is important

It allows unprotected protocols like HTTP to travel across a secure tunnel and adds following features to the HTTP

Server Authentication
Make sure that we are talking to the server that we are expecting to call. Without TLS we have no guarantee that the server at the other end of the channel is the same server that we intended to call.This is achieved by using x.509 certificates
Integrity Protection
Make sure that middleman between client and server can't modify the content. This is also achieved by using x.509 certificates with hashed content.
Replay protection
Make sure same request can't be repeatedly send to the server.
confidentiality
Make sure the messages client send to the server are properly encrypted so that nobody in the middle cannot see the content on the wire.

In modern web applications TLS is a must ensuring Confidentiality and Integrity without affecting Availability.

Security Fundamentals 1 - What is CIA

2015-04-07T16:36:00+00:00

In computer security CIA is the abbreviation for following terms.

Confidentiality
Integrity
Availability

Confidentiality

This means keeping the information secure from unauthorized access. The technologies involved are encryption, authentication, and authorization(access control)

Integrity

This means information should be consistent, accurate, and valid. This is achieved by using Hashing algorithms.

Availability

This means information should be available when required. This is achieved by using correct SLAs and preventing DOS attacks

How to Issue the Claims About the User

2015-03-30T11:43:00+00:00

This post is part of few introductory blog posts about the identity in DotNet Application. In this post, let’s talk about the process of storing and issuing claims about the user.

The claims are basically key-value pairs that say something about the authenticated user. These key-value pairs should be stored somewhere against the user’s identity. As we are going through the default ASP.NET template, Let’s see how claims are stored in the DB.

You can see following connection string in the web.config file

<add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\aspnet-AuthenticationExamples-20171022124844.mdf;Initial Catalog=aspnet-AuthenticationExamples-20171022124844;Integrated Security=True"
      providerName="System.Data.SqlClient" />

Let’s use either server explorer or SQL server management studio to see the DB.

As you can see ASPNETUserClaims table store the ClaimType and ClaimValue pairs against UserId.

Now let’s see how we these values are stored and retrieved using code.

Let’s create simple console app and use the default connection string(see above) used in asp.net default template.

PM> Install-package Microsoft.AspNet.Identity.Core -Version 2.2.1
PM> Install-package Microsoft.AspNet.Identity.EntityFramework -Version 2.2.1

The SignInManager uses the UserManager class internally to validate user password. UserManager is the main service that store and retrieve users and claims from the data store.

So using our console app we can add a claim for an existing user as follows

var userStore = new UserStore<IdentityUser>();
var userManager = new UserManager<IdentityUser, string>(userStore);
var user = userManager.FindByEmail("weliwita@gmail.com");
var claim = new IdentityUserClaim();
claim.ClaimType = ClaimTypes.Role;
claim.ClaimValue = "Administrator";
user.Claims.Add(claim);
userManager.Update(user);

Similarly, we can retrieve claims from user manager as follows

var userStore = new UserStore<IdentityUser>();
var userManager = new UserManager<IdentityUser, string>(userStore);
var user = userManager.FindByEmail("weliwita@gmail.com");
var claims = user.Claims;

UserManager is capable of performing many tasks related user. e.g account lockout, two-factor authentication using SMS service etc… See the documentation for more details.

Now we know how claims are stored and retrieved using the ASP.NET default template. The template uses libraries(see Nuget Packages above) belong to ASP.NET Identity. There are other similar libraries to manage users and claims. Membership reboot is one such library(Update-It is deprecated as of 2017).

In the default template, UserManagement is part of the application itself. As you can see in the template itself, it is a lot of code and learning curve for an application developer. So nowadays applications tend not to handle user management.

If an application doesn’t want to handle user management who can? Let’s discuss it in another post.

HTML Helper to Display the Logged In User’s DisplayName

2015-03-22T07:01:00+00:00

It is pretty common to display the logged-in user in various places in a website. We can create an HTML helper to display the logged-in user’s name.

public static MvcHtmlString UserDisplayName(this HtmlHelper htmlHelper)
{
    if (htmlHelper.ViewContext.HttpContext.Request.IsAuthenticated)
    {
        ClaimsPrincipal principal = htmlHelper.ViewContext.HttpContext.User as ClaimsPrincipal;
        if (principal == null)
        {
            throw new InvalidCastException("The current principal is not a claims principal.");
        }

        var nameClaim = principal.Claims.FirstOrDefault(t => t.Type == "name"); //use any claim that need to be displayed as UserDisplayName
        if (nameClaim != null)
        {
            return new MvcHtmlString(nameClaim.Value);
        }
    }

    return new MvcHtmlString("Anonymous");

}

Then the helper can be used on the navigation bar or any other UI widget that need to display user name.

<ul class="nav navbar-nav navbar-right">  
    <li class="dropdown navbar-text">
        Hi, @Html.UserDisplayName()
    </li>
</ul>

List All the Claims of the Current User

2015-03-09T05:02:00+00:00

The easiest way to display all the claims that was issued to the current user is to query the Identity property of the IPrincipal interface.

Here is the sample code in razor view.

@{
    var identity = (System.Security.Claims.ClaimsIdentity)User.Identity;
}

<ul>
    @foreach (var x in identity.Claims)
    {
        <li> claim:@x.Type -> @x.Value</li>
    }

</ul>

Running web application locally as a predefined user using OWIN Middleware

2015-03-01T09:29:00+00:00

It is quite common that we sometimes need to run the application without all the identity server redirection dance at development time. It is possible to assign common identity to all the users running the application locally as follows.

Create a custom authentication middleware as follows.

public class LocalAuthenticationMiddleware : OwinMiddleware
{
    
    public LocalAuthenticationMiddleware2(OwinMiddleware next) :
        base(next) { }

    public override async Task Invoke(IOwinContext context)
    {
        var response = context.Response;
        var request = context.Request;

        response.OnSendingHeaders(state =>
        {
            var resp = (OwinResponse)state;

            if (resp.StatusCode == 401)
            {
                resp.Headers.Add("WWW-Authenticate", new[] { "Basic" });
                resp.StatusCode = 403;
                resp.ReasonPhrase = "Forbidden";
            }
        }, response);

        // use this identity only if running locally
        if (request.Uri.IsLoopback)
        {
            var claims = new[]
                    {
                        new Claim("name", "Administrator"),
                        new Claim(ClaimTypes.NameIdentifier, "0001"),
                        new Claim(ClaimTypes.Role, "SiteAdministrator"),
                    };
            var identity = new ClaimsIdentity(claims, "Basic");
            request.User = new ClaimsPrincipal(identity);

        }

        await Next.Invoke(context);
    }
}

Then use the custom authentication middleware in the application startup

app.Use(typeof(LocalAuthenticationMiddleware));

Access the claims via Controller.User API.

var nameClaim = (User as ClaimsPrincipal).Claims.FirstOrDefault(t => t.Type == "name");

References

basic authentication

How to use Identity in a .NET Web Application - Part 1

2015-02-15T08:57:00+00:00

In a previous post, I described how does a user is represented inside a DotNet application using Thread.CurentPrinciple property. In this post and next, I will go through the default visual studio 2013 MVC template to see how the identity is set for an MVC application.

Let’s say in the default template you put authorize attribute in the About action in Home controller like follows.

[Authorize]
public ActionResult About()
{
    ViewBag.Message = "Your application description page.";
    return View();
}

If you now try to navigate to /Home/About you will receive is a 302 redirect to /Account/Login?ReturnUrl=%2FHome%2FAbout

Let’s see what is happening inside the OWIN pipeline.

To get details within OWIN pipeline we can inject some additional logging components as follows. Here we have injected two middleware components before and after cookie authentication middleware.

app.Use(async (Context, next) =>
{
    Debug.WriteLine("1 ==>request, before cookie auth");
    Debug.WriteLine("1 ==>context.response="+ Context.Response.StatusCode);
    await next.Invoke();
    Debug.WriteLine("4 <==response, after cookie auth");
    Debug.WriteLine("4 ==>context.response=" + Context.Response.StatusCode);
}); 

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath = new PathString("/Account/Login"),
    ...
});

app.Use(async (Context, next) =>
{
    Debug.WriteLine("2 ==>context.response=" + Context.Response.StatusCode);
    Debug.WriteLine("2 ==>request, before controller action");
    await next.Invoke();
    Debug.WriteLine("3 <==response, after controller action");
    Debug.WriteLine("3 ==>context.response=" + Context.Response.StatusCode);
});

If you now issue a request to /Home/About page you get following debug output.

==>request, before cookie auth
==>context.response=200
==>context.response=200
==>request, before controller action
<==response, after controller action
<==context.response=401
<==response, after cookie auth
<==context.response=302

See how response changed from 200 to 401 after the controller action. The Authorize attribute has detected that Thread.CurentPrinciple doesn’t contain a valid identity and has issued a 401 Unauthorized response.

This 401 response then go through the cookie authentication middleware and it then changes the 401 Unauthorized into 302 Redirect. The cookie authentication middleware knows where user should be redirected to get authenticated by using the LoginPath property. It also knows the URL user originally requested. So it can easily construct the redirect URL to the login page as follows

/Account/Login?ReturnUrl=%2FHome%2FAbout

Let’s see how login process takes place in the next post.

References

Brock Allen has this great article about the cookie authentication middleware.

Inside{CurlyBraces}

The Controversial Practice of SSL Inspection - A Betrayal of Trust?

Attaching Windbg to Managed Application

The Infinite Loop Technique

VS Code Integrated Terminal with Visual Studio Command Prompt

Troubleshooting

Transport Layer Security (TLS)

What is Transport Layer

What is Transport Layer Security (TLS)

Why it is important

Server Authentication

Integrity Protection

Replay protection

confidentiality

Security Fundamentals 1 - What is CIA

Confidentiality

Integrity

Availability

Related Links:

How to Issue the Claims About the User

HTML Helper to Display the Logged In User’s DisplayName

List All the Claims of the Current User

Running web application locally as a predefined user using OWIN Middleware

References

How to use Identity in a .NET Web Application - Part 1

References