administrators

What might be the main reason we don't see this?

There is not much added value with this in my opinion. As you already noticed these information would be fake anyway. Actually, I find it useful that if somebody has a look at the certificate (most don't care anyway) it would be obvious that this is not the original CA but a local one explicitly provided for SSL inspection.

Would there be a better alternative, if we would like to preserve this information for the client?

While most end users don't care as long as the browser does not complain, for some it would be useful to get the original certificate and chain, i.e. not a similar one but the real one. This could for example be done by providing a specific URL where the intercepting proxy simply delivers information about the original certificate as was seen by the proxy, i.e. something like https://proxy/give-me-the-original-cert?domain=.... I know of at least one product which has implemented this approach at the request of a customer.

In this environment an intercepting HTTPS proxy is used for legitimate purposes and its CA root certificate is installed on all clients. Every HTTPS proxy solution I've seen so far simply signs a new certificate directly with the CA, not preserving any information on the original certification path. After the proxy has made its decision, it's impossible to see what the original certification path was, which would be helpful for further evaluation in both success and failure.

It would be possible for the proxy to recreate the whole path of fake certificates instead of the one fake certificate, as demonstrated in this matrix on row "proposal". Of course, examining these certificates in detail would be rather useless, as they have fake keys, but this would preserve information on their CN, the dates they are valid between etc.

My questions:

1. What might be the main reason we don't see this?

   • It's assumed that users won't examine the certificate anyway.
   • The additional resources this would consume on the proxy.

2. ...or do we? Any examples of such intercepting proxies?

3. Would there be a better alternative, if we would like to preserve this information for the client?

I'm fairly certain that the SSH keys do not grant the user any GitHub-specific privileges; actions can only be taken in the scope of what git allows on the server, which shouldn't include account-related actions.

However, it may be possible for them to overwrite your commit history and force-push. I'm not sure if this would be permanent damage.

Personally I'd be more worried about unauthorized commits, e.g. backdoors added and such.

I connect to my github repo using ssh keys which I have whitelisted in GitHub. I do pull/push to this repo from my linux server which is hosted in AWS.

If a hacker gains access to this AWS server, what all damage can he do to my code in github? Can he/she remove my repos permanently from GitHub?

As you probably know already WebSockets does not implement any authentication or authorization methods by design, so the only possible way is to implement that on your own or use methods provided by frameworks like Django. Implementing secure authentication is hard.

From the technical point of view, you just have no other option but to send the authentication information with Cookies header. The only security requirement that comes in my mind for WebSockets you have to remember is to use secure connection, so "wss://" is a must.

Another thing is how you use the value send by cookie header on the server-side. The values included in cookie headers are considered as not safe as those are under the control of a user (sender). You should validate incoming values if it is not providing any malicious payload (SQL Injection, XSS), that could harm your backend. In your example, you are sending token value to a database so you should be aware of SQL injection (but not only) and provide correct mitigations into DB queries.

For input validation please refer to this OWASP Cheat sheet For SQL injection mitigation refer to this SQL Injection Cheat Sheet

The next thing is more general, how you use the token. You are passing the token into the database and on behalf of this, you are returning the user. It looks like you are using the token like user ID (I cannot be sure). Using the JWT as an authentication info you should consider a couple of things:

• data stored in the token are not changeable, if some data about the user will change, you have to generate a new token
  • you have to validate the JWT token on every call according to the standard
  • I would highly recommend to use encrypted JWT tokens, which is more secure but also adds additional overhead on cryptography operations.

You have to take those points into consideration and analyze the pros and cons regards to your use case from the perspective of usability, security, and possibly performance.

In regards JWT please refer to these links: JWT Authentication Best Practices - please check also the links at the bottom of this article and articles comments.

I am by no means a security engineer , and I have barely started my journey as a web developer. I'm utilizing a Python package known as Django for my backend and react.js for my front end. Recently I have incorporated django-channels, which is a package that gives me the ability to use websockets in my project. Since I have decoupled my front and backends , the basis of authentication I'm using is via tokens (will look into using JWT).

The issue is that with JavaScript , it is not possible to send authentication headers via websocket connection (or so I'm told) , therefore a lot of people are using cookies to send this authentication token instead. Here\s an example snippet of how I am sending the token from my front end:

 const path = wsStart + 'localhost:8000'+ loc.pathname
    document.cookie = 'authorization=' + token + ';' 
    this.socketRef = new WebSocket(path)

Doing this allows me to then extract out the token information through utilizing a customized middleware on my backend:

import re
from channels.db import database_sync_to_async
from django.db import close_old_connections

@database_sync_to_async
def get_user(token_key):
    try:
        return Token.objects.get(key=token_key).user
    except Token.DoesNotExist:
        return AnonymousUser()


class TokenAuthMiddleware:
    """
    Token authorization middleware for Django Channels 2
    see:
    https://channels.readthedocs.io/en/latest/topics/authentication.html#custom-authentication
    """

    def __init__(self, inner):
        self.inner = inner

    def __call__(self, scope):
        return TokenAuthMiddlewareInstance(scope, self)


class TokenAuthMiddlewareInstance:
    def __init__(self, scope, middleware):
        self.middleware = middleware
        self.scope = dict(scope)
        self.inner = self.middleware.inner

    async def __call__(self, receive, send):
        close_old_connections()
        headers = dict(self.scope["headers"])
        print(headers[b"cookie"])
        if b"authorization" in headers[b"cookie"]:
            print('still good here')
            cookies = headers[b"cookie"].decode()
            token_key = re.search("authorization=(.*)(; )?", cookies).group(1)
            if token_key:
                self.scope["user"] = await get_user(token_key)

        inner = self.inner(self.scope)
        return await inner(receive, send) 


TokenAuthMiddlewareStack = lambda inner: TokenAuthMiddleware(AuthMiddlewareStack(inner))

However this has raised some form of security red flags (or so I'm told) .

Therefore I wish to extend this questions to the security veterans out there :

1. Is this methodology of sending token authentication information via cookie headers safe?
2. Is my implementation of this method safe?
3. Is there a way to secure this even further?